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ABSTRACT 


A  major  problem  in  the  military  wargaming  arena  is  the  difficulty 
in  understanding  and  utilizing  currently  available  user  interfaces. 
Users  span  a  broad  range  in  terms  of  rank,  background,  technical 
skill,  perspective,  and  computer  literacy.  Military  workloads  and 
complexity  of  computer  and  wargaming  systems  preclude  familiarity 
with  system  interfaces.  New  users  are  inundated  with  a  variety  of 
obstacles,  including  unfamiliar  hardware  and  cryptic  command  struc¬ 
tures.  as  well  as  widely  varying  wargaming  software  systems.  In  most 
cases,  in-depth  training  is  required  before  a  wargaming  session  can 
commence,  thus  consuming  valuable  time,  resources,  and  money. 

This  thesis  pursues  the  specific  application  of  the  “visual"  inter¬ 
face  and  windowing  to  the  user  interface  of  wargaming  systems  for  the 
purpose  of  improving  the  utility  and  usability  of  these  systems  to  their 
users  and  sponsors. 
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the  Two  JTLS  Scenarios . 


I. 


A.  PURPOSE  OF  THESIS 

The  purpose  of  this  thesis  is  to  examine  the  most  effective  utiliza¬ 
tion  of  currently  available  technology  for  the  enhancement  of  user 
interfaces  for  wargaming  systems,  in  particular  the  Joint  Theatre  Level 
Simulation  (JTLS)  and  the  Battle  Group  Tactical  Trainer  (BGTT).  The 
JTLS  is  a  theatre-level  computer-assisted  wargaming  system  which 
models  two-sided  air,  ground,  and  naval  combat.  The  JTLS  was  pro¬ 
duced  for  joint  military  usage.  The  BGTT  is  a  computer-based  large- 
scale  simulation  of  the  naval  warfare  environment  and  was  produced 
for  use  by  the  United  States  Navy.  Both  systems  have  far  reaching 
utilization  by  numerous  commands  and  individuals. 

The  author,  having  spent  three  years  as  a  systems  analyst  at  the 
United  States  Readiness  Command  during  the  development  of  JTLS, 
recognizes  the  need  for  improvements  in  the  ease  of  use  of  the  JTLS 
system  as  well  as  similar  large-scale  wargaming  systems.  A  level  of 
player  training  of  one  to  two  weeks  in  duration  is  common  before  they 
are  competent  to  properly  control  the  execution  of  a  JTLS  wargame 
exercise.  In  other  systems,  it  is  common  for  trained  dedicated  opera¬ 
tors  to  act  as  assistants  to  the  players  and  provide  the  player-machine 
interface.  Even  though  the  investment  of  time  and  money  in  those 
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operators  is  considerable,  it  seems  that  the  expenditures  are  justified 
due  to  a  high  usage  rate  of  the  gaming  system. 

Since  the  design  and  implementation  of  the  JTLS  and  BGTT  sys¬ 
tems,  the  technology  available  for  implementation  of  more  effective 
user  interfaces  has  been  successfully  implemented  and  proven  in 
general-purpose  systems  as  well  as  other  special-purpose  systems. 
This  available  technology  has  not  been  applied  in  these  two  actual 
wargaming  systems  even  though  it  shows  promise.  Through  the  use  of 
such  systems  and  well -developed  user  interfaces,  the  casual  user  can 
rapidly  be  imbued  with  a  level  of  skill  such  that  he  can  effectively  per¬ 
form  within  a  greatly  abbreviated  time  span. 

One  available  technology  is  that  of  the  visual  interface.  A  well- 
known  implementation  of  a  visual  interface  is  in  the  Macintosh  micro¬ 
computer  system.  The  Macintosh  system  uses  icons  and  a  pointing 
device  as  a  means  of  communication  between  the  computer  and  the 
user.  A  large  part  of  the  system's  success  can  be  attributed  to  the 
“Desktop"  metaphor,  which  allows  the  user’s  familiarity  with  common 
desktop  items  to  be  transferred  to  the  control  of  the  computer  system 
itself.  The  extent  of  visual  expression  in  the  Macintosh  system  is  veiy 
strong. 

Another  vital  aspect  of  technology  which  has  developed  since  the 
design  of  JTLS  and  BGTT  is  that  of  hardware  efficiency.  Lowering 
hardware  costs  coupled  with  increased  capabilities  has  brought  forth  a 
new  affordable  level  of  graphics  utilization  in  computer  systems. 


A  number  of  current  systems  developers  are  exploring  the  use  of 
windowing  and  window  management  which,  to  be  implemented  effec¬ 
tively,  need  these  graphics  capabilities.  Because  hardware  is  more 
reasonably  priced  and  software  has  reached  high  levels  of  sophistica¬ 
tion,  widespread  use  of  windowing  and  graphics  is  now  feasible.  Since 
windowing  technology  itself  showrs  a  great  deal  of  merit  and  room  for 
application  in  general,  this  thesis  will  look  at  windowing  and  its  possi¬ 
ble  applications  in  wargaming. 

B.  METHODOLOGY 

l.  User  Interface  Research 

The  beginning  of  this  study  took  a  very  broad  perspective  of 
the  user  interface  and  improvement  thereof.  It  was  a  preliminary 
assumption  that  the  user  interfaces  of  large-scale  wargaming  systems 
have  a  strong  need  for  improvement.  Beyond  that  was  the  question. 
“How  should  those  improvements  be  made?" 

A  review  of  user  interface  literature  was  undertaken  to  search 
for  answers  to  this  question.  As  a  result  of  that  investigation,  it  was 
the  author’s  opinion  that  much  of  the  literature  was  inconclusive  in 
defining  an  operating  environment  where  a  user's  performance  can  be 
optimized  wrtth  a  minimum  of  training.  The  information  available  was 
very  general  and  totally  void  of  functional  models  for  practical 
application. 


There  exist  a  number  of  user  interface  guideline  “checklists" 
which  enumerate  the  many  criteria  of  a  “good"  user  interface.  The 
most  prominent  of  these  is  titled  Guidelines  for  Designing  User 
Interface  Software,  by  Sydney  L.  Smith  and  Jane  N.  Mosier.  Addition¬ 
ally.  Ben  Schneiderman,  an  expert  in  the  design  of  user  interfaces,  has 
authored  several  books  on  the  subject. 

Unfortunately,  systems  developers  must  measure  many  task- 
specific  needs  within  their  application  against  these  checklists  only  to 
produce  a  vague  and  confusing  mental  model  of  what  they  need  to 
produce.  After  this  process,  there  is  no  guarantee  that  the  interface 
will  be  effective.  It  may  merely  consist  of  a  spaghetti  of  favored 
attributes.  Therefore,  such  guidelines  may  be  helpful  in  making  spe¬ 
cific  user  interface  decisions,  but  a  ground-up.  full-scale  system 
approach  presents  many  perplexing  questions.  In  this  respect,  the 
literature  search  proved  to  be  lacking  in  fully  developed  models  for 
proven  and  accepted  user  interfaces. 

The  literature  did.  however,  reflect  a  favorable  direction  in 
user  interface  technology  which  is  now  gaining  wide  acceptance.  This 
technology  could  represent  a  general  model  for  the  development  of 
user  friendly  interfaces.  It  is  the  graphic-based  visual  interface  tech¬ 
nology.  Basically,  the  visual  interface  Is  the  use  of  “visual  expressions." 
a  combination  of  text  and  graphics  used  for  communication  under  a 
system  of  interpretation.  The  Macintosh  is  the  currently  accepted 
“standard"  of  the  visual  type  of  interface. 


In  parallel  with  the  user  interface  research,  several  masters 
level  projects  and  theses  were  reviewed.  One  Naval  Postgraduate 
School  student,  Rob  Irving,  developed  a  program  where  the  Macintosh 
acted  as  a  command  input  terminal  to  the  Naval  Warfare  Interactive 
Simulation  System  (NW1SS,  predecessor  to  BGTT).  His  objective  was 
to  “take  advantage  of  the  Macintosh  windowing  and  mouse  features 
and  incorporate  the  NWISS  command  syntax  in  the  software  to  pro¬ 
duce  a  method  of  rapidly  entering  error-free  commands."  The  project 
successfully  demonstrated  that  the  concepts  of  the  Macintosh  system 
user  interface  allow  “rapid  and  easy  command  input  for  NWISS"  with¬ 
out  prior  knowledge  of  the  NWISS  command  syntax  (Irving,  1986). 

A  thesis  produced  by  Mark  J.  Sweeney  and  Kenneth  J.  Bitar 
(1986)  did  further  research  on  the  question  of  implementation  of  user 
friendly  input  devices  to  the  NWISS.  This  study  favored  the  use  of 
continuous  voice  input  over  that  of  a  Macintosh  interface  “if  subject 
training  time  is  not  a  significant  restriction."  Standard  keyboard  entry 
and  continuous  voice  input  were  favored  for  trained  participants.  The 
results  reflect  that  users  of  the  Macintosh  interface  had  only  thirty- 
five  minutes  training  each  to  practice,  as  opposed  to  six  hours  training 
on  the  voice  system  and  high  "lifetime  exposure  to  keyboard  technol¬ 
ogy."  Additionally,  the  Macintosh  input  terminal  had  the  lowest  error 
rate  under  certain  conditions.  They  concluded  that,  with  a  minimum 


of  introduction  to  a  speech  or  Macintosh  system,  near-equal  perfor¬ 
mance  can  be  attained  to  that  of  an  experienced  typist. 

Recently,  in  another  Naval  Postgraduate  School  thesis,  a 
masters  student  studied  the  design  and  development  of  a  prototype 
for  a  visual  interface  to  the  Joint  Theatre  Level  Simulation  (JTLS).  He 
concluded  that  “a  graphical  application  of  the  game  is  a  very  efficient 
and  desirable  method  to  effect  player  inputs."  (Lower,  1987) 

Investigation  of  other  research  in  the  area  of  the  user  inter¬ 
face.  and  particularly  the  visual  interface,  led  to  the  Naval  Ocean 
Systems  Center.  San  Diego,  where  the  development  of  a  knowledge 
based  graphical  interface  is  underway.  This  system  is  proposed  to  be 
the  “command  center  of  the  future."  It  takes  advantage  of  compo¬ 
nents  of  the  visual  interface  as  well  as  voice  input/ output  technology 
and  shows  great  promise  for  allowing  the  user  to  interact  in  a  more 
natural  and  efficient  workstation. 

3.  Wargamc  Research 

A  portion  of  research  has  been  directed  at  the  two  applica¬ 
tions,  JTLS  and  BGTT.  Research  has  been  conducted  through  direct 
interaction  with  the  systems,  study  of  the  available  documentation, 
observation  of  game  playing  by  organized  teams,  and  interviews  with 
sponsors  as  well  as  users.  The  user  interfaces  have  been  compared 
and  contrasted.  The  primary  criteria  for  selection  of  these  two  sys¬ 
tems  in  this  study  are:  1)  they  are  both  major  systems,  widely  used 
and  recognized,  and  2)  they  directly  contrast  in  the  primary  input 


methodology.  The  JTLS  Is  basically  a  menu-driven  system  while  BGTT 
is  primarily  a  direct  syntactical  command  entry  system. 

During  the  development  process,  sponsors  and  users  are 
often  forced  to  conceptualize  “what  they  want"  long  before  they  have 
any  idea  of  what  they  really  need.  To  further  complicate  problems,  the 
user  interface  issues  may  not  be  addressed  due  to  the  overwhelming 
motivation  to  successfully  model  realistic  simulation  of  war.  It  is 
common  for  interface  considerations  to  take  a  “back  seat"  to  every¬ 
thing  else  with  the  assumption  that  they  hold  less  importance  and  will 
eventually  fall  into  place  anyway. 

Common  problems  observed  in  the  large-scale  wargaming 
systems  include,  but  are  not  limited  to: 

1)  Navigation  problems.  Users  find  themselves  lost,  not  knowing 
where  they  are  within  the  command  structure  and  not  knowing 
what  action  to  take  next. 

2 )  Syntax  errors  and  complex  command  structure  problems.  Users 
make  repeated  errors  and  need  lists  of  commands  with  the 
appropriate  syntax  at  their  side  during  play. 

3)  Speed  problems.  The  complexity  of  the  systems  coupled  with 
the  simulation  speed  provide  a  compounded  problem  for  the 
player  who  is  trying  to  stay  abreast  of  simulation  events. 

4)  Developer  support.  Due  to  game  complexity,  developer  support 
is  often  required  for  long  periods  of  time  after  delivery  for 
imparting  understanding  of  the  system  and  user  training. 

5)  User  interface  representation.  The  systems  are  very  difficult  to 
learn  and  use,  and  very  easy  to  forget.  There  Is  no  standardiza¬ 
tion  in  the  interface.  Even  with  all  the  variations  in  existing  user 
interfaces  none  are  notably  "user  friendly." 
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6)  Output  overload.  Users  find  themselves  searching  through 
numerous  status  reports  and  other  output  in  attempts  to  find  the 
information  they  need  to  continue  effective  game  play. 

C.  SCOPE  AND  DIRECTION 

As  discussed  earlier,  preliminary  research  shows  strong  promise 
in  development  of  visual  user  interfaces  in  wargaming.  While  the 
wargaming  environment  is  complex,  an  enhancement  to  the  user 
interface  may  provide  enhanced  usability  and  thus  improved  ease  and 
frequency  of  utilization,  which  will  provide  increased  information 
capabilities  and  decreased  costs.  Increased  information  capabilities 
will  be  a  direct  result  of  increased  usage,  which  will  be  possible  due  to 
lower  overhead  in  both  time  and  money.  Cost  decreases  in  terms  of 
dollars  should  be  derived  from  lower  training  and  personnel  support 
costs. 

From  this  point,  this  thesis  will  present  a  survey  of  wargaming, 
including  general  descriptions  of  the  JTLS  and  BGTT  systems  and 
their  respective  user  interfaces.  Research  will  further  encompass  an 
in-depth  analysis  of  the  attributes  of  a  visual  interface.  The  Macintosh 
system  will  provide  a  case  study  of  a  successful  visual  interface  imple¬ 
mentation  methodology.  Then  the  formulation  of  a  general  wargame 
visual  interface  model  will  be  introduced  with  specific  recommenda¬ 
tions  for  the  JTLS  and  BGTT  systems. 


A.  THE  HISTORY  OF  WARGAMING 

Wargaming  today  takes  on  many  forms  and  functions,  but  the  his¬ 
tory  of  wargaming  shows  that  the  development  of  wargames  has 
brought  the  games  through  various  states  of  favor  as  well  as  disfavor  by 
assorted  groups  of  users.  Before  discussing  the  history  of  wargaming, 
a  definition  of  wargaming  is  in  order.  “A  wargame  is  a  simulation,  by 
whatever  means,  of  military  operations  involving  two  or  more  opposing 
forces,  conducted  using  rules,  data,  and  procedures  designed  to 
depict  an  actual  or  assumed  real  life  situation."  (DON.  1985,  p.  2-1) 

Early  war  games,  during  the  seventeenth  century,  were  military 
chess  or  war  chess  games  which  had  two  sides  of  equal  strength,  each 
with  known  dispositions  but  unknown  intentions.  These  games  were 
further  developed  with  the  concepts  of  aggregation  and  terrain  fea¬ 
tures.  One  of  these  games— the  King’s  Game  (developed  in  1644  by 
Christopher  Weikhmann)— was  used  extensively  as  a  practical  aid  to 
military  training.  Another  game,  called  War  Chess,  was  played  on  a 
board  of  1,666  squares  and  was  used  to  train  military  officers  of 
Germany.  France.  Austria,  and  Italy  (Fox,  p.  8). 

In  1811.  the  von  Reisswitz  game  was  developed.  It  was  the  first 
game  to  break  away  from  the  chessboard  environment.  Terrain  was 
modeled  In  sand  at  first.  Colored  paper  attached  to  blocks  was  used  to 


represent  troops.  The  king  of  Prussia  sponsored  this  game,  which 
became  operational  in  an  improved  version  with  porcelain  game 
pieces  and  plaster  terrain  (DON.  p.  3-1).  Czar  Nicolas  played  this 
game  in  Russia  (Fox,  p.  9). 

Further  modifications  of  the  von  Reisswitz  game  were  made  by  his 
son  in  1824,  including  using  a  map  instead  of  a  sandtable  and  writing  a 
set  of  improved  rules  for  playing  the  game.  Forces  were  represented 
by  properly  proportioned  metal  pieces  and  rules  were  based  on  realis¬ 
tic  troop  movement  rates  as  well  as  delays  in  communications. 
Opposing  forces  were  designated  red  and  blue,  which  is  a  convention 
still  used  in  most  wargames.  A  designated  umpire  used  dice  with 
varying  numbers  of  sides  along  with  number  tables  to  determine  out¬ 
comes  and  assess  battle  losses.  This  game  was  called  the 
“Kriegsspiel"  and  gained  wide  acceptance  (Fox.  p.  9). 

Kaiser  Wilhelm  II  ordered  that  the  Kriegsspiel  be  adopted  by  the 
German  Army.  In  time,  the  improved  Kriegsspiel  spread  to  virtually 
every  country  with  a  standing  military.  Professional  groups  formed  to 
play  the  Kreigsspiel  and  clubs  sprang  up  to  promote  interest  in  the 
game.  Also  during  this  period,  Alfred  Graf  Schliefifen,  Chief  of  the 
German  General  Staff  from  1892  to  1906,  used  the  game  extensively 
for  experimentation  to  develop  a  series  of  "Schlieffen  Plans"  for  the 
invasion  of  Belgium  and  France  in  World  War  I  (Fox,  p.  10). 
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After  World  War  1.  Interest  shifted  from  rigid  play  to  free  play  of 
the  game.  This  method  was  characterized  by  disposal  of  the  strict 
rules  in  exchange  for  dependence  upon  the  judgement  of  the  game 
director  for  game  decisions.  This  was  a  forerunner  for  the  type  of 
political/military  game  now  played  by  policy  makers  worldwide. 

Germany  continued  extensive  use  of  the  wargame  during  the  first 
half  of  the  twentieth  century.  Wargaming  flourished  under  Hitler  and 
was  credited  for  the  smoothness  of  at  least  the  initial  operations  of  the 
German  invasion  of  France  and  Belgium  (Fox,  p.  11).  Unit  commander 
knowledge  was  in  large  part  derived  from  wargame  experience,  since 
after  1918  the  wargame  became  an  important  part  of  the  German  offi¬ 
cer's  training. 

Japan  used  wargames  as  educational  tools  in  their  war  college 
because  the  successes  during  the  Russo-Japanese  War  of  1904  were 
directly  attributed  to  wargaming  (DON,  p.  3-3).  The  Japanese  used 
wargaming  extensively  prior  to  World  War  II.  Pearl  Harbor  and  the 
occupation  plan  for  the  Pacific  were  gamed  in  a  session  of  far-reaching 
scope  conducted  by  Admiral  Yamamoto,  the  Japanese  combined  fleet 
commander  in  chief  (Fox,  p.  12). 

American  involvement  in  wargaming  was  minor  during  this 
period.  In  the  early  stages,  the  United  States  adapted  German  games 
which  were  introduced  in  the  army  in  1867.  The  first  American  work 


on  wargaming  was  entitled  “The  American  Kriegsspiel"  and  was  pub¬ 
lished  by  Major  W.  R.  Livermore  in  1879  (DON,  p.  3-3). 

Captain  Alfred  T.  Mahan,  president  of  the  Naval  War  College, 
expressed  strong  interest  in  a  series  of  lectures  on  wargaming  pre¬ 
sented  by  William  McCarty  Little  in  1887.  This  provided  the  founda¬ 
tion  on  which  continued  wargaming  activity  has  long  been  based  at  the 
Naval  War  College  (DON.  p.  3-4).  Prior  to  World  War  II,  wargaming  was 
generally  confined  to  the  service  schools  for  the  purpose  of  training, 
though  the  United  States  Navy  is  credited  with  “considerable  fore¬ 
sight’"  because  of  the  wargaming  activity  during  World  War  II  (Fox, 

p.  12). 

Since  World  War  II.  the  introduction  of  the  digital  computer  has 
dramatically  changed  the  face  of  wargaming.  The  capability  of  high¬ 
speed  computation  and  simulation  techniques  have  given  even  greater 
flexibility  to  the  gamers  for  educational  as  well  as  analytical  utilization 
of  the  now  numerous  available  wargames. 

Today,  wargaming  is  used  for  many  applications.  Force  planning, 
research,  development  of  operation  plans,  and  education  and  training 
are  the  primary  uses.  Education  and  training  Is  by  far  the  most  exten¬ 
sive  use.  The  service  war  colleges  as  well  as  other  military  education 
commands  have  well-developed  and  extensively  used  wargaming  capa¬ 
bilities.  Other  world-wide  commands,  many  of  which  are  operational. 


use  wargames  for  strategic  and  operational  planning,  training,  and 
exercise  support. 


B.  CURRENT  SYSTEMS 

As  mentioned  above,  there  are  numerous  wargames  available  to 
users  today.  Although  manually  played  wargames  are  still  in  use,  this 
thesis  will  address  only  wargames  implemented  on  digital  computers. 
Specifically,  the  systems  to  be  addressed  are  two  current  major 
wargame  systems  in  popular  use  throughout  the  Department  of 
Defense  today,  the  Joint  Theatre  Level  Simulation  (JTLS)  and  the 
Battle  Group  Tactical  Trainer  (BGTT). 

1.  The  JTLS  System 

The  Joint  Theatre  Level  Simulation  (JTLS)  is  a  computer- 
assisted  wargaming  system  which  models  two-sided  air,  ground,  and 
naval  combat.  It  can  be  used  for  warfare  training.  Joint  operational 
planning,  and  doctrinal  analysis.  The  model  is  theatre  independent 
(CPS.  p.  2-1). 

JTLS  was  developed  by  the  Jet  Propulsion  Laboratory  for  a 
consortium  originally  consisting  of  the  United  States  Readiness 
Command,  the  United  States  Army  War  College,  and  the  United  States 
Army  Concepts  Analysis  Agency.  This  JTLS  system  was  formed  as  an 
effort  to  develop  a  model  general  enough  to  address  each  agency’s 
fundamental  questions  and  yet  rich  enough  to  be  useful  throughout  the 
joint  Department  of  Defense  community.  The  design  of  JTLS  is  based 
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on  a  very  extensive,  detailed  user  requirements  study  and  the  use  of 
computer  simulation  capabilities. 

The  JTLS  software  is  designed  to  operate  on  the  Digital 
Equipment  Corporation  VAX  11  series  minicomputer.  Associated  with 
the  VAX  system  are  various  storage  media  and  input/output  devices. 
The  minimum  input/output  hardware  configuration  consists  of  four 
video  terminals  and  one  on-line  printer.  In  the  minimum  configura¬ 
tion.  the  technical  coordinator  and  controller  each  have  one  terminal, 
and  each  force  commander  has  one  terminal.  The  number  of  players 
is  flexible  to  meet  various  gaming  and  personnel  requirements.  It  is 
desirable  to  have  a  graphics  display  and  input  pad  for  each  commander 
and  the  controller.  The  “standard"  game  configuration  consists  of  ten 
video  terminals,  three  graphics  displays,  and  three  printers. 

2.  The  BGTT  System 

The  Battle  Group  Tactical  Trainer  (BGTT)  is  implemented  as 
a  real-time  interactive,  discrete  event,  time  step  computer  simulation 
of  the  naval  warfare  environment.  The  BGTT  supports  two-sided  play 
and  an  umpire-like  control  function  which  handles  neutral  forces  and 
can  monitor  or  participate  in  scenarios  (NOSC,  p.1-1). 

The  BGTT  was  developed  for  use  by  the  United  States  Navy  to 
address  the  tactical  aspects  of  naval  warfare.  The  BGTT  can  be  used 
for  evaluation  of  new  tactics  and  doctrines,  support  of  major  at-sea 
exercise  planning  and  reconstruction,  analysis  of  proposed  or 
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postulated  fleet  requirements,  and  validation  of  command  control 
requirements  (NOSC,  p.1-4). 

The  BGTT  software  is  partitioned  into  five  major  functions 
and  is  designed  to  operate  on  the  Digital  Equipment  Corporation  VAX 
1 1  series  minicomputers  in  conjunction  with  MEGATEK  Corporation 
graphics  display  systems  and  various  interface  devices  configured  in 
up  to  a  maximum  of  eight  command  centers. 

C.  THE  JTLS  AND  BGTT  SYSTEMS  USER  INTERFACES 
1.  Defining  a  User  Interface 

Stating  the  definition  of  a  user  interface  is  at  the  same  time 
defining  other  older,  but  commonly  used  terms  such  as  “man-machine 
interface"  or  “human-computer  interface."  Specifically,  the  user 
interface  is  the  site  of  interaction  between  the  user  and  the  computer. 
The  user  generates  inputs  and  the  computer  generates  outputs. 

In  conventional  systems,  the  primary  method  of  user  input  is 
by  keyboard  while  the  primary  method  of  output  is  from  a  video 
screen.  Other  systems  have  brought  forth  a  wide  variety  of  input  and 
output  devices.  The  inclusion  of  hardware  devices  alone  in  the  defini¬ 
tion  of  the  user  Interface,  though  important,  is  somewhat  Incomplete. 

A  distinguishing  factor  in  any  user  interface  is  the  driving 
software  of  the  application  Involved,  which  controls  the  manner  and 
methods  of  interaction.  This  software  decides  what  control  actions 
will  be  effected  and  what  representations  will  be  displayed  to  the  user. 
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In  effect,  this  portion  of  the  user  interface  governs  the  interaction  at 
hand. 

The  user  Interface  Is  becoming  recognized  as  a  significantly 
more  important  part  of  any  computer  system  application  because  of 
the  strong  effect  of  the  interface  on  the  effective  and  efficient  utiliza¬ 
tion  of  the  application.  The  tremendous  expenditure  of  money  and 
resources  is  of  little  value  if  the  users  lack  operating  skills,  alertness, 
or  motivation. 


The  JTLS  user  interface  is  provided  by  one  of  four  funda¬ 
mental  programs  called  the  Model  Interface  Program  (MIP).  This 
software  provides  a  continuous  interaction  between  the  warfare  simu¬ 
lation  model  and  the  players.  The  Model  Interface  Program  provides 
the  following  capabilities: 

1)  Entering  orders. 

2)  Processing  orders. 

3)  Communication  between  players  and  controller. 

4 )  Communication  between  players  and  the  warfare  simulation. 

5)  Accessing  and  using  support  information. 

6)  Saving  orders  in  Order  History  Files. 

The  Model  Interface  Program  is  a  purely  menu-driven  inter¬ 
face  with  structured  command  entry  and  template  fill-in  (CPS,  p.  3-8). 


Separate  graphics  software  provides  graphic  representations 
in  the  user  interface  on  a  dedicated  graphics  display  screen.  Current 
tactical  situations  can  be  displayed  in  color  with  graphics  which  have 
zoom  capabilities  (to  change  map  scale)  as  well  as  iconic  and  textual 
unit  information.  Graphic  representations  are  in  the  form  of  Defense 
Mapping  Agency  maps  overlaid  with  text  and  standard  military  unit 
symbology. 

User  interface  hardware  in  a  JTLS  workstation  consists  of  a 
Digital  Equipment  Corporation  VT-100  video  terminal  or  a  VT-100 
compatible  terminal,  and  a  graphics  display  system  comprised  of  a 
large- screen  Sony  monitor  and  a  GTCO  graphics  pad. 

The  VT-100  terminal  provides  command  input  via  a  menu 
driven  system  with  templates.  Commands  may  be  “stacked”  or  syn¬ 
tactically  listed  instead  of  following  the  structured  menu  interface. 
The  terminal  screen  is  divided  into  three  portions.  The  divisions 
provide  a  game  status  line  at  the  top,  an  output  area  in  the  center  of 
the  screen,  and  an  input  area  at  the  bottom. 

The  status  line  provides  game  security  classification,  player 
terminal  function,  game  speed,  number  of  messages  waiting  to  be 
read,  and  game  time  expressed  in  date-time  group  format.  The  center 
portion  of  the  screen  provides  game  output  in  the  form  of  messages 
and  various  game  reports.  This  space  is  also  used  to  display  templates 
which  are  currently  being  used  to  complete  command  input.  The 


lower  portion  Is  for  game  Input.  Keystrokes  are  displayed  to  this  area 
and  echoed  to  the  appropriate  template  area.  See  Figures  1  and  2  for 
typical  JTLS  command  entry  screens  (CPS.  p.  5-3  and  5-14). 

The  graphics  pad  and  monitor  allow  graphic  status  of  the 
game  to  be  represented  to  the  player  on  a  frequently  updated  basis. 
Information  regarding  unit  status  such  as  unit  strength  is  depicted 
continuously,  while  more  specific  information  such  as  actual  lati¬ 
tude/longitude  may  be  chosen  by  selection  using  the  graphics  device. 

Since  JTLS  graphics  were  produced  later  in  the  development 
cycle,  the  addition  was  an  extremely  welcome  one.  Before  JTLS 
graphics  became  available,  primary  information  for  game  play  was 
most  often  derived  from  game  reports  and  status  displays  on  the 
VT-100.  Depending  on  the  type  of  information  required,  this  may  still 
be  the  case. 

3.  The  BGTTJ/gcr  Interface 

The  Wargame  mode  of  BGTT  provides  the  user  interface.  It 
provides  a  set  of  orders  which  allow  the  users  to  control  game  action 
and  progress.  Specifically,  information  display  orders  and  force  con¬ 
trol  orders  are  the  commands  available  to  a  player  during  the  game. 
These  orders  are  syntactic  commands  of  the  following  general  format: 


key  (system  output)  <data  entry>. 


JTLS  COMMAND  SELECTION  MENU 


JTLS  Template 


“Key"  is  equal  to  the  key  words  of  the  order.  System  output  refers  to 
the  parenthetical  expressions  output  by  the  system  to  explain  or 
prompt  for  the  next  item  of  data  to  be  supplied  by  the  user.  Data  entry 
refers  to  expressions  appearing  within  the  <>  symbols  denoting  the 
required  user  entered  data.  For  example,  an  order  in  BGTT  may 
appear  as  follows: 

DEFINE  CHAFF  (life  of)  <minutes>  (width)  cnautical  miles>  (depth) 
<feet>. 

Use  of  keyboard  entry  allows  order  key  words  to  be  entered  in  abbre¬ 
viated  form  if  a  unique  portion  of  the  command  is  entered. 

An  alternate  method  of  command  entry  is  available  to 
BGTT  players.  A  menu  display  is  available  to  help  the  user  sequence 
the  fields  within  the  order  and  also  sequence  the  various  orders 
through  the  use  of  color  on  the  display.  The  orders  are  displayed  on 
the  geotactical  color  display  console.  As  an  aid  to  the  user,  the  orders 
are  displayed  in  a  menu  format,  showing  the  correct  syntax  and 
allowable  options  with  system-generated  prompting  to  assure  proper 
order  entry.  This  function  is  provided  through  combined  use  of  the 
graphics  display  and  tablet  with  a  puck  selecting  device  or  optional 
joystick. 

The  user  interface  hardware  in  BGTT  consists  of  a  number  of 
possible  items,  but  a  standard  command  center  configuration  will  have 
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one  operator  input/output  terminal  with  a  keyboard,  a  color  graphic 
geographical  and  tactical  display,  several  black  and  white  monitors  to 
display  automatic  status  boards  (usually  four  are  used),  a  graphics 
tablet,  and  an  intercom  for  communication.  Other  options  include  a 
joystick,  a  large  screen  display,  a  printer/plotter,  and  a  voice 
synthesizer.  See  Figures  3  and  4  (NOSC,  p.  1-1-3)  . 

The  BGTT  interface  is  elaborate  in  the  provision  of  multiple 
frequently  updated  terminal  screens.  Four  text-based  automatic  status 
board  screens  as  well  as  one  graphics  screen  are  continuously  available 
for  player  reference.  The  overall  effect  of  this  interface  along  with  the 
integrated  voice  communication  system  is  the  achievement  of 
relatively  lifelike  command  center  environment. 

4.  User  Interface  Problems 

In  spite  of  concerted  efforts  by  developers  and  sponsors  to 
provide  clear,  reasonably  easy-to-use  interfaces,  wargames  today  are 
lacking  in  the  necessary  components  for  meeting  the  needs  of  a  fast- 
moving  modem  military  environment.  A  major  source  of  cost  in  the 
military  wargaming  arena  is  training  users  to  a  level  of  proficiency 
where  the  systems  can  be  utilized  efficiently.  There  is  often  consider¬ 
able  difficulty  in  understanding  and  utilizing  currently  available  user 
interfaces. 

Users  span  a  broad  range  in  terms  of  rank,  background,  tech¬ 
nical  skill,  perspective,  and  computer  literacy.  Military  workloads  and 


Typical  BGTT  Command  Center 
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complexity  of  computer  and  wargaming  systems  preclude  familiarity 
with  system  interfaces.  New  users  are  inundated  with  a  variety  of 
obstacles  including  unfamiliar  hardware  and  cryptic  command  struc¬ 
tures.  as  well  as  widely  varying  wargaming  software  systems.  In  most 
cases,  in-depth  training  is  required  before  a  wargaming  session  can 
commence,  thus  consuming  valuable  time,  resources,  and  money. 

The  primary  goal  in  a  wargame  used  for  the  purpose  of  train¬ 
ing  and  education  is  to  develop  and  refine  warfare  skills.  Unfortu¬ 
nately.  the  above-mentioned  complexities  of  the  systems  and  the 
widely  varied  skill  levels  of  the  users  create  difficult  circumstances 
which  must  be  overcome  before  reaping  intended  benefits.  A  large 
portion  of  available  training  time  is  often  spent  teaching  the  user  to 
interface  with  the  system. 

In  other  cases,  where  the  wargame  is  used  for  planning  or 
analysis,  players  are  subject  to  extended  hours  of  play  as  well  as 
repeated  play.  Typing  input  in  syntactically  correct  phrases,  which  is 
in  Itself  difficult  enough,  becomes  increasingly  difficult  with  fatigue. 
Although  the  players  involved  may  play  a  particular  game  on  a  regular 
basis  and  may  become  very  familiar  with  the  interface,  if  interest  is 
lost  and  fatigue  causes  errors,  the  resulting  analyses  may  be  invalid. 
Additionally,  familiarity  with  one  or  two  Interfaces  does  not  guarantee 
any  transfer  of  understanding  since  there  is  very  little  consistency  or 
standardization  in  the  available  interfaces. 
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In  addition,  the  military  personnel  system  creates  frequent 
personnel  turnovers,  which  in  turn  dictates  that  experienced  person¬ 
nel  are  frequently  replaced  by  inexperienced  personnel.  It  is  not 
uncommon  for  thorough  training  of  an  inexperienced  user  on  a  com¬ 
plex  wargaming  system  to  take  months  or  in  some  cases  years  before 
required  job  proficiency  is  attained. 

General  problems  of  cryptic  command  structures,  inconsis¬ 
tent  interfaces,  computer  system  hardware  and  software  complexities, 
as  well  as  the  intricacies  of  the  wargames  themselves  create  a  myriad 
of  problems  for  training  commands  and  sponsor  commands. 

Specific  problems  are  numerous.  It  has  been  observed  that 
players  cannot  learn  commands  and  therefore  cannot  play  without 
notes  and  manuals  at  their  sides.  Even  with  these  memory  aids,  play¬ 
ers  still  find  their  input  commands  have  syntax  errors  and  their  input 
parameters  are  often  far  from  reality  and/or  the  sponsor’s  intentions. 

Another  problem  is  information  overload.  As  players  partici¬ 
pate  in  the  game,  automatic  reports  are  generated  on  screen  and  on 
paper,  inundating  the  user  with  a  lot  of  unusable  information  due  to 
the  fact  that  he  cannot  find  what  he  needs.  The  user  has  little  or  no 
control  over  the  information  and  the  presentation  of  that  information. 

This  brings  us  to  the  problem  of  control.  The  wargame  player 
is  controlled  by  the  system  in  a  sort  of  maze-like  race.  The  player  is 
continually  trying  to  keep  up  with  the  game  action  while  trying  to 


figure  out  how  to  use  the  system  and  interface,  not  to  mention  his 
efforts  to  grasp  the  relevant  portions  of  the  database  he  is  supposed  to 
be  using,  all  at  the  same  time. 

Even  structured  menu  and  template  input  causes  trouble 
be'cause  users  become  “lost"  in  the  command  structure  or  menu  tree. 
Navigation  problems  are  a  major  difficulty  in  these  systems  for  the 
unfamiliar  user.  Additionally,  there  is  often  no  escape  from  inadver¬ 
tent  choices  or  mistakes.  It  is  not  uncommon  for  a  player  to  find 
himself  in  the  lower  level  of  a  menu  tree  to  realize  that  he  is  not 
where  he  wants  to  be.  He  then  may  request  help,  follow  the  advice,  if 
available  and  clear,  then  try  to  figure  out  how  to  accomplish  what  he 
originally  intended  to  do. 

Such  problems  are  compounded  by  lack  of  experience  with 
hardware,  computers,  and/or  wargame  simulation  models  in  general. 
Often  users  do  not  know  how  to  perform  simple  tasks  on  the  com¬ 
puter  and  keyboard  such  as  the  use  of  function  keys  or  interpretation 
of  user  messages  on  the  screen.  Often,  users  require  not  only 
wargame  training,  but  fundamental  computer  skill  training. 

The  purpose  of  this  thesis  is  to  take  wargame  system  inter¬ 
face  problems  and  examine  an  alternative  method  of  user  interface. 
No  efforts  in  the  area  of  standardization  have  been  approached  in  the 
currently  available  wargame  user  interfaces.  In  the  following  chapter, 
this  thesis  will  examine  the  Macintosh  interface  standard  produced  by 


A.  A  USER-FRIENDLY  INTERFACE 


1.  The  Macintosh-like  User  Interface 

The  Macintosh  microcomputer  system  represents  a  new 
standard  in  the  microcomputer  industry.  As  described  later,  the 
Macintosh  has  a  number  of  characteristics  which  differentiate  it  from 
other  systems.  There  are  many  reports  of  very  positive  reactions 
regarding  the  use  of  this  system.  Some  of  these  reactions  include 
feelings  of: 

1 .  Control  of  the  system. 

2.  Competence  in  task  performance. 

3.  Intuitive  ease  in  learning  the  system. 

4.  Ease  in  assimilating  advanced  features. 

5.  Confidence  in  retention  of  skills. 

6.  Enjoyment  in  using  the  system  (Schneiderman,  p.180). 

Based  on  research  done  by  Xerox  corporation,  the  Macintosh 
user  interface  is  very  different  from  traditional  approaches.  It  is  the 
result  of  several  years  of  intensive  research  on  how  people  interact 
with  computers  and  how  the  interface  should  be  designed  to  be  both 
highly  productive  and  painless  for  its  users.  (Simpson,  1986,  p.  2) 
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The  vision  was  to  bring  the  power  and  versatility  of  com¬ 
puters  to  ordinary  people  (Apple  Computer,  1986,  foreword  p.  ix). 
Although  the  concepts  created  by  Apple  were  initially  introduced  in 
the  Lisa  microcomputer  system,  the  Macintosh  represents  the  most 
mature  and  successful  implementation  of  those  efforts.  An  interesting 
result  of  the  Macintosh  has  been  that  it  allows  both  computer  experts 
and  novices  to  share  and  appreciate  the  technology. 

The  Apple  Macintosh  user  interface  was  designed  to  enhance 
the  effectiveness  of  the  people  using  the  system.  This  approach  is 
generally  called  user  friendly,  although  Apple  calls  it  user  centered. 
And  while  the  interface  is  often  called  simple,  Apple  maintains  that  the 
terms  direct  and  effective  make  more  sense  (Apple  Computer,  1986, 
p.  2). 

The  Macintosh  user  interface  is  called  the  Apple  Desktop 
Interface  or,  to  the  indoctrinated  Macintosh  user,  the  Desktop.  The 
principle  on  which  the  Desktop  is  based  is  that  of  a  metaphor  for  an 
actual  working  space  on  one’s  desk.  It  is  a  concrete  metaphor  with 
which  we  are  all  familiar  in  our  daily  lives.  This  metaphorical  founda¬ 
tion,  and  the  way  it  is  represented  to  and  manipulated  by  the  user, 
accounts  for  the  tremendous  success  of  this  system.  It  is  presented  in 
common  terms,  which  makes  it  more  easily  understandable,  and  it  is 
comfortable. 


a.  Hardware  Elements  of  the  Macintosh  User  Interface 


The  Macintosh  system  uses  a  mouse  and  keyboard  for 
input,  and  a  printer  and  a  high-resolution,  bit-mapped  screen  for 
output.  The  high  resolution  graphics  screen  is  a  key  feature  of  the 
Macintosh.  The  black  and  white  screen  consists  of  175,104  (512 
horizontal  x  342  vertical)  pixels.  This  allows  applications  to  be  pre¬ 
sented  to  users  in  effective  combinations  of  text  and  graphics.  The 
use  of  graphic  objects  for  commands,  parameters,  and  features  is 
promoted  strongly  in  the  Macintosh  user  interface.  The  high  resolu¬ 
tion  capability  of  the  video  screen  supports  this  goal. 

The  Macintosh  has  a  highly  visual  interface  which 
requires  not  only  the  standard  use  of  a  keyboard  for  entry  but  also  a 
mouse.  A  mouse  is  a  pointing  device  which  allows  users  to  select 
desired  actions  by  pointing  to  an  object  on  the  screen  and  clicking  a 
button  on  top  of  the  mouse. 

The  mouse,  keyboard,  high-resolution  monitor,  and 
printer  are  common  elements  in  microcomputing  today.  What  makes 
the  Macintosh  unique  is  its  software.  The  software,  including  ROM 
routines,  is  the  basis  for  the  special  user-computer  dialog. 

A  user-computer  dialog  is  a  two-way  conversation 
between  the  user  and  the  computer.  The  user  is  presented  with  pos¬ 
sible  choices  on  the  video  screen  and.  instead  of  making  the  tradi¬ 
tional  direct  command  entry  or  menu  selection  by  keyboard,  the 
Macintosh  user  will  most  likely  point  to  a  graphically  depicted  object 


and  click  the  mouse  to  select  it.  A  large  percentage  of  operations 
completed  by  the  user  will  generally  involve  such  selection  of  graphic 
representations  with  the  mouse. 

b.  Software  Elements  of  the  Macintosh  User  Interface 

The  Macintosh  operating  system  and  Finder  software  are 
universal  across  Macintosh  applications.  They  provide  the  basis  for 
interaction  and  control.  The  operating  system  provides  essential 
functions  such  as  interrupt  handling,  memory  management,  and 
input/output  to  keep  the  Macintosh  functioning  (Apple  Computer, 
1983,  p.  3).  With  the  Finder  software,  the  user  can  manipulate  flies 
and  start  up  applications.  In  normal  operation,  it  is  automatically  the 
first  program  to  be  run  when  the  Macintosh  is  turned  on  (Chemicoff. 
1985,  p.  591). 

There  are  a  number  of  visual  components  in  the  Macin¬ 
tosh  interface  which  are  used  for  such  tasks  as  file  manipulation  and 
program  interaction.  These  visual  components,  as  mentioned  above, 
are  icons,  windows,  dialog  and  alert  boxes,  pull-down  menus,  and 
other  symbolic  control  devices.  These  representations  are  imple¬ 
mented  in  software  application  programs  by  calls  to  the  ROM.  which 
provides  them  as  standardized  functions.  Most  of  these  functions  are 
graphic  in  nature. 

As  one  may  note,  the  Macintosh  system  is  composed  of  a 
complex  foundation  of  interface  software.  This  interface  software  may 


40 


be  accessed  through  the  Macintosh  128-kilobyte  ROM  and  is  called 
the  User  Interface  Toolbox.  Application  programmers  may  therefore 
call  from  their  programs  the  standard  routines  which  provide  the 
broad  range  of  facilities  and  features  of  the  Macintosh  interface. 

The  system,  while  somewhat  difficult  to  learn  to  pro¬ 
gram.  can  present  a  very  friendly  interface  to  its  user.  The  most 
important,  and  possibly  the  most  difficult,  part  of  programming  the 
Macintosh,  however,  is  to  put  the  Macintosh  design  philosophy  into 
effect.  It  is  quite  possible  to  develop  an  application  which  integrates 
the  excellent  features  of  the  Macintosh  User  Interface  Toolbox,  yet 
very  poorly  presents  an  effective  user  interface.  Therefore,  great  care 
must  be  taken  in  using  such  a  system.  There  is  no  panacea,  but  there 
are  helpful  guidelines  available  to  the  developer. 


2.  Lessons  Learned  From  This  System 

Due  to  the  recognition  that  even  the  best  tools  if  not  properly 
used  are  of  little  or  no  value.  Apple  Computer  has  developed  two  very 
helpful  sets  of  principles  for  the  developer  of  Macintosh  applications. 
These  principles  are  based  on  extensive  research  which  should  prove 
useful  in  programming  most  any  visual  interface.  The  first  set  of  prin¬ 
ciples  relates  to  general  design  principles.  The  second  set  relates  to 
the  principles  of  graphic  communication, 
a.  General  Design  Principles 

1 )  Metaphors  from  the  real  world.  “Use  concrete  metaphors  and 
make  them  plain,  so  that  users  have  a  set  of  expectations  to 


apply  to  computer  environments."  (Apple  Computer,  1986,  p.  3) 
Audio  and  visual  effects  that  support  the  metaphor  should  be 
used  whenever  possible.  This  is  based  on  the  fact  that  most 
users  are  not  experts  but  people  do  have  direct  experience  in 
their  immediate  world.  Therefore,  using  familiar  concepts 
makes  users  feel  comfortable. 

2)  Direct  manipulation.  This  should  be  used  to  give  the  user  a 
sense  of  control  over  the  activities  of  the  computer.  Direct 
manipulation  is  based  on  the  fact  that  people  expect  physical 
actions  to  result  in  some  sort  of  physical  feedback.  Therefore, 
moving  the  mouse  results  in  a  corresponding  move  of  the 
pointer  or  cursor,  and  clicking  the  close  box  of  a  document 
causes  it  to  shrink  into  an  icon  representing  the  document. 

3)  See-and-point.  Users  should  be  allowed  to  select  actions  from 
alternatives  presented  on  the  screen.  This  allows  users  to  see- 
and-point  (as  opposed  to  remember-and-type).  Recognition,  not 
recall,  is  important  here;  the  user  should  not  have  to  remember 
anything  the  computer  already  knows.  It  is  simple  for  most 
programmers  and  expert  users  to  work  with  a  command -line 
interface  that  requires  memorization  and  Boolean  logic.  This  is 
not  a  simple  task  for  the  average  user.  Through  the  use  of  a 
visual  and  spatial  environment,  people  are  able  to  work  effec¬ 
tively  while  using  the  computer  in  a  sensible  human 
environment. 

This  removes  the  burden  of  learning  and  remembering  cryp¬ 
tic  or  complex  command  structures,  thus  allowing  the  user’s 
focus  to  be  on  the  actual  task.  Recognition  rather  than  recall  is 
all  that  is  needed  for  successful  operation. 

4)  Consistency.  “Effective  applications  are  both  consistent  within 
themselves  and  consistent  with  one  another."  (Apple  Computer, 
1986,  p.  6)  The  very  important  reason  for  this  point  is  that  of 
skill  transfer.  If  a  user  is  accustomed  to  the  interface  of  one 
application  and  that  application  is  consistent  with  others  in 
operational  concepts  and  elements,  then  the  skills  used  may  be 
transferred  to  other  applications. 

5)  WYSIWYG  (what  you  see  is  what  you  get).  “There  should  be  no 
secrets  from  the  user,  no  abstract  commands  that  only  promise 
future  results.  There  should  be  no  significant  difference 
between  what  the  user  sees  on  the  screen  and  what  eventually 


gets  printed.”  (Apple  Computer.  1986,  p.  7)  This  concept 
means  that  user  actions  result  in  feedback  which  corresponds 
with  actions  taken.  An  action  to  copy  a  file  to  another  disk  dis¬ 
plays  the  copy  in  both  places,  the  original  and  the  new,  thus 
assuring  the  user  that  the  action  resulted  in  the  desired  effect. 
Also,  a  document  will  be  printed  as  displayed  on  the  screen. 
The  user  does  not  have  to  guess  or  perform  uncomfortable 
manipulations  to  achieve  the  desired  output.  This  is  in  direct 
support  of  the  direct  manipulation  concept. 

6)  User- initiated  actions.  All  man-machine  interaction  should  be 
driven  by  the  user,  not  the  system.  The  user  is  no  longer  in  a 
reactive  state  to  a  machine.  A  user  may  receive  warnings  if  he  is 
about  to  take  a  risk,  but  the  user  still  maintains  control  and  is 
allowed  to  make  his  choice  of  action,  not  the  computer’s. 

7)  Forgiveness.  Even  the  most  proficient  user  makes  mistakes. 
The  system  should  be  forgiving  when  mistakes  occur.  Since 
provided  documentation  is  often  avoided  by  users  and  since  this 
avoidance  takes  on  a  form  of  exploration,  users  should  be 
allowed  to  learn  by  doing.  In  support  of  this,  naive  or  inattentive 
users  should  be  warned  before  making  unrecoverable  mistakes. 

8)  Feedback  and  dialog.  The  user  should  be  kept  informed.  Feed¬ 
back  should  be  immediate  and  clear.  “User  activities  should  be 
simple  at  any  moment,  though  they  may  be  complex  taken 
together."  (Apple  Computer,  1986,  p.  8)  The  user  must  remain 
informed  to  maintain  his  state  of  control  over  the  environment. 
Also,  the  user  needs  to  be  aware  of  the  progress  of  operations 
and  be  presented  with  brief,  direct  explanations  if  operations 
cannot  be  completed. 


9) 


Perceived  stability.  “Users  feel  comfortable  in  a  computer  envi¬ 
ronment  that  remains  understandable  and  familiar  rather  than 
changes  randomly."  (Apple  Computer.  1986,  p.  9)  The  inter¬ 
face  provides  a  two-dimensional  visual  stability  and  a  conceptual 
sense  of  stability  with  a  clear  finite  set  of  objects  and  actions 
within  the  fast  and  versatile  computer  environment. 


10)  Aesthetic  integrity.  "Visually  confusing  or  unattractive  displays 
detract  from  the  effectiveness  of  human-computer  interactions. 
Different  ‘things’  look  different  on  the  screen.  Users  should  be 
able  to  control  the  superficial  appearance  of  their  computer 
workplaces—  to  display  their  own  style  and  individuality."  (Apple 
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Computer,  1986.  p.  10)  The  visual  appearance  of  the  screen  and 
its  components  Is  essential  to  the  Macintosh  Interface.  Apple 
states  that  “Consistent  visual  communication  is  very  powerful  in 
delivering  complex  messages  and  opportunities  simply,  subtly, 
and  directly.”  (Apple  Computer,  1986,  p.  10) 

b.  Principles  of  Graphic  Communication 

Apple  Computer  has  further  guidelines  which  address 
the  graphic  aspects  of  the  interface.  “Graphics  are  not  merely  cos¬ 
metic.  When  they  are  clear  and  consistent,  they  contribute  greatly  to 
ease  of  learning,  communication,  and  understanding.  The  success  of 
graphic  design  is  measured  in  terms  of  the  user’s  satisfaction  and  suc¬ 
cess  in  understanding  the  interface."  (Apple  Computer.  1986,  p.  11) 

Further.  Apple  has  three  primary  measures  for  effective 
graphic  presentation:  visual  consistency,  simplicity,  and  clarity. 
These  support  the  concept  of  conveying  real  world  metaphors  in  a 
context  which  will  be  most  appropriate  to  the  application  and  com¬ 
fortable  for  the  user  (Apple  Computer,  1986,  pp.  11-12). 


B.  THE  VISUAL  INTERFACE 
1-  lifting  YltUll 

The  Macintosh  system  is  certainly  not  the  only  system  which 
has  taken  advantage  of  a  visual  interface.  The  Macintosh’s  direct  pre¬ 
decessor  was  the  Lisa  microcomputer  system  by  Apple  Computer.  The 
Lisa  system  heavily  influenced  a  number  of  products,  including 
“Microsoft  Windows,"  “GEM"  by  Digital  Research,  and  IBM’s 
“TopView." 


The  Lisa  system  began  to  take  shape  after  the  Apple  senior 
staff  visited  Xerox's  Palo  Alto  Research  Center  in  1980  to  see  a 
demonstration  of  Smalltalk.  At  the  end  of  a  three-year  development 
period,  the  Lisa  was  introduced  as  the  first  multitasking  windowing 
system  for  a  personal  computer.  The  Lisa  did  not  prove  to  be  suc¬ 
cessful  in  sales,  but  much  of  the  technology  was  passed  to  the  higher- 
performance.  lower-cost  Macintosh.  Many  of  the  user  interface 
concepts  used  in  the  Macintosh  were  in  fact  developed  for  use  in  the 
Lisa  (Tesler.  1985,  pp.  17-22). 

The  Xerox  Star  system  is  a  widely  known  system  which  is 
credited  as  a  forerunner  in  the  implementation  of  a  visual  interface. 
Announced  in  1981,  Star’s  use  of  icons,  pointing  devices,  and  an  office 
metaphor  predate  the  Lisa  and  Macintosh.  The  system  had  strong 
limitations  in  that  the  system  addressed  the  visual  interface  only  at  a 
very  simple  level.  To  perform  in  an  application  environment.  Star  was 
used  in  a  command  mode  much  like  other  types  of  systems  (Shu, 
1986,  p.  21). 

The  significance  of  the  aggregate  work  discussed  above  is  that 
it  brought  forth  a  new  standard  of  user  interface  which  can  be  called 
the  visual  interface.  A  visual  interface  uses  visual  objects  as  the  basis  of 
communication.  “A  visual  communication  object  is  some  combination 
of  text  and  graphics  used  for  communication  under  a  system  of  inter¬ 
pretation,  or  visual  language."  The  benefit  of  visual  communication  is 


“When  humans  are  faced  with  cognitive  complexity,  they  often  need 
graphics  as  well  as  text  to  help  them  deal  with  that  complexity." 
(Lakin,  1986,  p.  36) 

If  appropriately  applied,  the  visual  interface  is  capable  of 
bringing  positive  benefits  in  dealing  with  complex  problems  such  as 
military  wargaming.  The  benefits  are  even  more  noticeable  when  the 
visual  interface  is  contrasted  with  the  user  interfaces  of  the  past. 

The  typically  used  menu  and  command  structure  interfaces 
are  plagued  with  problems  in  the  areas  of  syntax,  modes,  and  naviga¬ 
tion.  The  visual  interface  easily  overcomes  these  problems  in  an  envi¬ 
ronment  centered  on  the  user’s  control  of  the  system.  Learning  time 
for  new  users  is  greatly  reduced  because  the  visual  interface  is  based 
on  familiar  and  intuitive  processes  and  actions. 

Given  the  particular  needs  and  goals  of  a  given  application, 
prototypes  of  the  visual  Interface  can  be  easily  implemented  and 
tested  for  maximum  effectiveness. 

2.  The  Design  of  a  Visual  Interface 

Ben  Shneiderman  (1986).  developed  a  model  called  “direct 
manipulation.'*  This  model  addresses  the  visual  interface  and  consists 
of  three  parts: 

1.  “Continuous  representation  of  the  objects  and  actions  of 
interest." 


2.  “Physical  actions  or  labeled  button  presses  Instead  of  complex 
syntax." 


3.  “Rapid  incremental  reversible  operations  whose  impact  on  the 
object  of  interest  is  immediately  visible." 

While  the  Macintosh  system  provides  an  example  of  a  visual 
system,  no  specific  design  models  have  been  formulated  for  guidance 
in  development  of  other  specific  applications  of  visual  systems.  Most 
research  supports  the  principles  which  Apple  developed  as  user 
interface  guidelines,  but  some  recommendations  should  be  empha¬ 
sized  before  undertaking  the  development  of  a  visual  interface. 

It  is  clear  that  a  visual  interface  in  and  of  itself  does  not  merit 
reward.  It  is  the  careful  and  planned  design  and  implementation  of 
the  visual  interface  through  which  its  many  rewards  may  be  reaped. 
Application  goals  must  be  carefully  integrated  with  the  user  needs  and 
the  principles  of  good  visual  interface  design.  This  is  a  primary 
requirement  and  it  is  recommended  that  strong  consideration  be 
given  to  the  ideals  of  this  approach  before  development  begins. 

As  mentioned  earlier,  the  visual  interface  can  be  easily  proto¬ 
typed  and  tested  for  effectiveness  within  the  context  of  any  appli¬ 
cation.  This  aspect  requires  considerable  graphic  creativity  and 
expertise.  Poorly  designed  graphic  tools  can  produce  only  poor 
results  within  the  application.  Careful,  application-specific  design 
considerations  must  be  created  to  communicate  with  the  user  clearly 
and  concisely. 

Icon,  window,  menu,  and  dialog  design  must  be  integrated 
into  more  than  a  “package"  that  works  together.  It  should  represent  a 


metaphor  of  reality  which  will  effectively  bring  the  abstract  actions  of 
the  computer  into  concrete,  realistic  terms  for  the  user. 

After  the  initial  graphic-based  design  takes  form,  a  consider¬ 
able  task  still  remains.  Follow-on  prototyping  and  thorough  testing  of 
the  design  are  critical  to  success.  Prototyping  tools  exist  which  allow 
relatively  simple  implementation  of  screen,  window,  dialog,  and  icon 
design.  User  interactions  and  reactions  may  be  prototyped  and  tested 
through  these  tools  as  well. 

The  prototyping  and  testing  phase  is  the  most  important 
aspect  of  the  user  interface  design  process.  The  best  plans  can  fail 
when  presented  to  the  user  who  can  not  or  will  not  effectively  use  the 
interface.  The  prototyping  methodology  is  highly  efficient  in  devel¬ 
opment  of  the  visual  interface  because  it  allows  low  cost  and  high 
speed  at  the  same  time.  This  is  necessary  and  most  productive  in  this 
type  of  situation. 

The  visual  interface  design  presents  special  problems  of  its 
own.  Since  screen  space  is  limited,  the  effective  use  of  window 
management  is  necessary.  The  following  section  presents  some 
important  considerations  in  windowing  methodology. 

C.  WINDOWING 

There  are  associated  concepts  which  are  of  importance  in  the 
design  and  implementation  of  windows. 


Windows  provide  views  for  the  user  into  applications.  As 
previously  discussed,  windows  may  occur  in  various  sizes,  shapes, and 
forms.  Windows  are  actually  complex  graphic  representations  which 
require  highly  efficient  software  structures  for  their  display  and  con¬ 
trol.  The  mechanism  which  usually  provides  this  service  is  a  Window 
Management  System. 

The  Workshop  on  Window  Management  defines  the  following: 
“A  Window  Management  System  (WMS)  is  a  system  service  that  pro¬ 
vides  for  the  creation,  deletion,  and  modification  of  windows.  The 
WMS  allocates  scarce  resources  (represented  by  on-screen  real  estate, 
entries  in  a  colour  map,  use  of  mouse  and  keyboard  input  devices) 
among  contending  applications."  (Hopgood,  et  al.  1986,  p.  145-147) 
Functions  of  a  WMS  as  defined  by  the  same  research  group  include: 

1 )  creating  and  destroying  windows: 

2)  redrawing  images  in  windows: 

3)  providing  titles  for  windows: 

4)  requesting  the  allocation  of  color  table  entries; 

5)  requesting  sampling  input  from  the  mouse,  keyboard,  or  other 
entry  device. 

Window  design  is  concerned  with  a  number  of  aspects,  from 
technical  to  functional,  to  aesthetic.  Assuming  that  technical  capabili¬ 
ties  exist  to  perform  the  desired  operations  at  acceptable  speeds, 
attention  turns  to  the  user  oriented  issues  of  function  and  aesthetics. 


■VW-V  V.V\A 


tT>> 


The  Application  Interface  Task  Group  of  the  Workshop  on  Window 
Management  defined  eight  principles  to  be  considered  in  window 
manager  design: 


1 )  Symmetry—  application  and  window  manager  should  be  able  to 
do  the  same  functions. 

2 )  Synchrony-  single  thread  of  control  should  exist. 

3)  Hints— impossible  tasks  initiated  by  applications  should  be 
allowed  graceful  exit  by  the  WMS. 

4)  Redraw  requests- requests  should  be  hidden  and  redraw  mech¬ 
anism  should  be  simple. 

5)  Procedural  interface— interfaces  should  be  procedural  as 
opposed  to  exposed  data  structures. 

6)  High  level  libraries— applications  should  talk  through  a  window 
manager  toolkit. 

7 )  Strategy  specification—  it  should  be  possible  to  specify  strategies 
such  as  font  or  color  matching. 

8)  Generality- this  principle  is  difficult  to  achieve.  The  research 
group  expects  compromise  in  this  area  (Hopgood.  et  al.  1986. 
pp.  213-214). 

Window  management  design  addresses  a  large  number  of 
control  issues  regarding  the  participation  level  of  the  WMS.  The  con¬ 
sensus  among  the  Workshop  on  Window  Management  is  that  most  of 
these  specific  Issues  should  be  dealt  with  at  the  application  level  in 
consideration  of  the  application  goals.  The  group  also  addressed  a 
number  of  important  general  issues  which  should  be  resolved  in  the 
future  to  establish  accurate  conclusions  regarding  future  development 
decisions  (Hopgood,  1986,  p.  172). 
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Implementation  of  a  Window  Management  System  requires 
the  observed  workings  of  the  system  by  the  user.  Creativity  could 
result  in  innumerable  variations  across  a  range  of  applications,  but 
guidelines  can  be  helpful  in  the  general  development  process.  Warren 
Teitelman  created  a  set  of  guidelines  for  development  of  an  environ¬ 
ment  where  the  user  is  expected  to  be  in  control  of  the  system.  He 
suggests  that  the  interface  should: 

1 )  Be  intuitive—  use  images  suggestive  of  operations  being 
performed. 

2)  Accommodate  novices  and  experts— to  enhance  growth  and 
flexibility  from  ease  of  use  to  power. 

3)  Allow  customization- allow  macro  mechanisms  for  expert 
customization. 

4)  Provide  extensibility— use  of  macros  to  extend  functionality. 

5)  Use  lots  of  feedback— inform,  but  avoid  intrusive  interaction  by 
appropriate  use  of  feedback. 

6)  Be  predictable— use  a  consistent,  uniform,  easily  remembered 
set  of  basic  actions. 

7)  Be  deterministic— predictable  methods  are  preferred. 

8 )  Avoid  modes—  avoid  states  that  persist. 

9)  Don’t  preempt  the  user— do  not  force  the  user  to  respond 
(Hopgood,  et  al.  1986.  pp.  187-188). 

The  working  group  agreed  that,  in  the  context  of  the  end 
user,  a  WMS  should  consider  the  user’s  model  to  define  standards  for 
interfaces.  Additionally,  the  group  agreed  that  present  methods  of 


representation  are  unsatisfactory,  and  that  there  is  presently  no  obvi¬ 
ous  means  of  standardization  of  the  user  interface.  Again,  further 
research  is  suggested.  In  this  case,  the  group  suggested  study  of 
existing  window  manager  models  and  better  ways  of  representing  user 
models  (Hopgood,  et  al,  1986,  pp.  189-190). 

Valuable  suggestions  were  offered  by  the  group  on  window 
implementation.  The  window  functions  should  be  provided  by  a 
toolkit  approach.  This  is  consistent  with  the  Apple  approach  to  win¬ 
dow  implementation  through  the  Toolbox  and  Window  Manager  soft¬ 
ware.  The  window  manager  should  provide  generic  functions  which 
can  be  interpreted  by  applications.  This  again  is  consistent  with  the 
Apple  implementation,  which  provides  generic  cut-and-paste  func¬ 
tions  as  well  as  others.  A  final  recommendation  is  that  “User  Interface 
Management  Systems  should  be  developed  which  enable  the  rapid 
tailoring  of  window  managers  to  application  requirements."  These 
systems  are  used  to  generate  window  managers.  (Hopgood.  et  al, 
1986,  p.  190-191) 

Since  windowing  is  a  critical  aspect  of  the  visual  interface, 
strong  consideration  and  support  should  be  given  to  WMS  develop¬ 
ment  in  the  context  of  specific  applications  by  sponsors  and  develop¬ 
ers.  The  success  or  failure  of  a  visual  interface  implementation  may  be 
rooted  in  the  WMS  and  adequate  resources  should  therefore  be 
allocated. 


The  visual  interface  of  today  is  dependent  on  windowing, 
although  future  implementations  may  explore  utilization  of  spatial 
information,  where  information  is  nested  in  spatial  images.  These 
images  may  be  thought  of  as  something  like  projections  of  information 
allowing  a  user  to  “zoom  in  and  out"  of  an  image  to  obtain  more  or  less 
information  regarding  that  item.  This  concept  is  used  by  the  Dataland 
system  developed  at  the  Massachusetts  Institute  of  Technology  (Bolt, 
1984,  p.  24).  Research  in  this  area  is  very  young  but  may  show  even 
greater  promise  than  the  visual  interface  we  commonly  know  today. 

The  visual  interface  is  effective  in  its  current  state  but,  as  just 
noted  above,  there  may  be  any  number  of  improvements  and  refine¬ 
ments  which  may  be  developed  in  the  future.  On  the  other  hand, 
improvement  may  take  the  form  of  an  integration  of  currently  available 
technology. 
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The  Decision  Support  System  literature  proposes  a  generic  archi¬ 
tecture  to  construct  a  user  interface  (Bui.  1987).  This  architecture 
consists  of  three  independent,  inter-related  modules:  1)  the  dialog 
unit.  2)  the  control  unit,  and  3)  the  inter-module  linkage  unit.  Various 
user  interface  representations  may  be  developed  within  this  generic 
model. 

The  purpose  of  the  dialog  unit  is  to  provide  the  input/output  links 
or  physical  interface  between  the  user  and  the  system.  The  software 
portion  of  the  dialog  unit  contains  routines  which  monitor  the  hard¬ 
ware.  The  hardware  portion  of  the  dialog  unit  may  include  a  CRT. 
keyboard,  mouse,  touchscreen,  printer,  or  other  varieties  of 
input/output  devices. 

The  control  unit  guarantees  smooth,  error-free  interaction 
between  the  user  and  the  system.  The  checking  of  syntax  and  logic  as 
well  as  provision  of  a  help  facility  is  the  responsibility  of  this  module. 
Correct  and  relevant  representation  to  the  user  is  the  primary  goal  of 
this  very  important  unit. 

The  inter-module  linkage  unit  provides  a  liaison  of  the  model  with 
the  data  components  or  other  elements  of  the  system. 


The  overall  goal  of  this  framework  is  to  provide  an  effective  and 
efficient  user  interface  design  strategy  focused  on  learning,  creativity, 
and  interaction  delivered  in  a  friendly,  helpful  fashion. 

B.  A  SURVEY  OP  USER  INTERFACE  REQUIREMENTS 

A  group  of  forty  graduate  students  from  the  Information  Science 
Department  at  the  Naval  Postgraduate  School  participated  in  a  survey 
regarding  the  design  of  a  wargaming  user  interface.  Students  were 
asked  to  address  each  of  the  three  aspects  of  the  above  model  with  a 
description  of  what  they  considered  important  components  of  an 
effective  wargaming  interface.  All  of  the  requirements  they  developed 
were  with  respect  to  the  above  framework. 

Students  participating  in  the  study  were  professional  military  offi¬ 
cers.  familiar  with  warfare  in  general  but  unfamiliar,  in  most  cases, 
with  wargaming  systems.  This  data,  therefore,  provides  information 
based  on  a  relatively  strong  understanding  of  the  user  interface,  with 
limited  exposure  to  the  direct  application  of  wargaming.  It  should  be 
noted,  however,  that,  as  professional  military  officers,  the  survey  par¬ 
ticipants’  training  and  Job  experience  lend  an  understanding  to  the 
strong  importance  of  the  content  and  purpose  of  wargaming  within 
the  military. 

The  surveys  were  reviewed  and  analyzed  by  compiling  a  list  of  fea¬ 
tures  recommended  by  the  survey  participants  for  each  of  the  three 
components  within  the  user  interface  framework  discussed  in  the 


previous  section.  Corresponding  recommendations  were  then  tallied 
and  ranked  in  descending  order  of  frequency. 

The  dialog  unit  brought  forth  the  most  varied  and  interesting  con¬ 
clusions  in  the  survey.  Survey  participants,  in  their  independent 
designs  of  a  dialog  component  for  a  wargaming  user  interface,  consid¬ 
ered  several  items  to  be  very  important.  Eighty-three  percent  of  the 
participants  recommended  a  high-resolution  graphics  monitor  as  the 
primary  output  device  in  the  system.  Most  participants  felt  that  a 
menu-based  system  was  preferable  to  a  command-driven  system,  and 
in  many  cases,  the  participants  felt  that  a  menu  system  should  be  sup¬ 
plemented  with  some  other  methodology  such  as  windowing  (thirty- 
eight  percent),  voice  input/output  (thirty-eight  percent),  icons 
(twenty  percent),  and/or  graphic  manipulation  (thirteen  percent). 

Sixty-three  percent  felt  that  a  mouse  input  device  was  preferred 
to  other  input  devices  such  as  touchscreens,  joysticks,  or  light-pens. 
Sixty  percent  of  the  participants  recommended  a  standard  keyboard, 
in  conjunction  with  the  mouse  or  alone,  although  only  a  very  small 
number  (five  percent)  of  the  participants  considered  using  the  key¬ 
board  alone. 

While  twenty  percent  of  the  participants  included  high-speed 
workstations  in  their  description,  seventy  percent  neglected  to  men¬ 
tion  color  as  an  important  characteristic  of  the  high-resolution 
graphics  monitor/workstation  concept.  The  criteria  most  often 


mentioned  as  important  to  the  user  were  response  speed  and  ease  of 
use. 

The  control  unit  portion  of  the  survey  found  that  the  participants 
most  highly  valued  an  on-line  help  facility.  In  fact,  this  item,  with  a 
seventy-percent  frequency,  had  the  strongest  support  of  all  items 
considered  in  the  survey.  Very  close  to  the  on-line  help  feature  was  a 
rigid  input/output  error-checking/verification  system  (ranking  sixty- 
three  percent),  which  the  participants  felt  was  necessary  in  any  appli¬ 
cation  supporting  a  wide  variety  of  users. 

Items  mentioned  with  respect  to  the  control  unit  were  all  soft¬ 
ware  related  except  for  one  item.  This  was  a  separate  or  front-end 
processor  to  provide  high-speed  and  responsiveness  to  the  user. 
Thirty  percent  of  the  participants  considered  this  necessary  to  pro¬ 
vide  adequate  control. 

The  remaining  recommendations  for  the  control  unit  were  to 
provide  simple  and  clear  prompts  and  messages  (twenty-eight  per¬ 
cent),  timely  and  informative  feedback  (twenty  percent),  forgiveness 
in  error  recovery  (fifteen  percent),  and  an  on-line  tutorial  (fifteen 
percent). 

In  the  inter-module  linkage  unit,  the  most  desirable  characteristic 
was  modular  implementation  (thirty-eight  percent)  for  the  purposes  of 
flexibility  and  maintenance.  Ranking  second  in  this  category,  with 
twenty-eight  percent  each,  were  rapid  access  via  a  local  central 


processing  unit  or  high-speed  memory  and  ease  of  data  access  and 
availability. 

The  participants  had  a  variety  of  responses  but,  in  general,  the 
above  provides  a  condensed  overview  of  the  most  desirable  character¬ 
istics  as  seen  by  prospective  users  of  wargaming  systems.  The 
developer  of  a  wargaming  user  interface  could  consider  these  char¬ 
acteristics  as  a  basis  for  a  simplified,  generic,  user  requirements 
definition  on  which  refinements  and  further  recommendations  could 
be  based. 

C.  A  FEASIBILITY  ANALYSIS  OF  DESIRABLE  WARGAMING 

CHARACTERISTICS 

In  the  previous  section,  different  characteristics  were  recom¬ 
mended  by  the  potential  users  surveyed.  As  is  typical  in  most  user 
surveys,  there  is  a  broad  base  from  which  developers  and  sponsors 
must  make  limited  selections.  The  determination  of  good,  productive, 
cost-effective  characteristics  must  remain  in  the  final  analysis  of  any 
successful  project.  Many,  although  not  all,  of  these  decisions  are  based 
on  a  union  of  user  and  application  requirements.  Other  factors  influ¬ 
encing  such  decisions  may  be  based  on  time,  hardware,  financial,  or 
political  constraints. 

This  portion  will  address  a  general  set  of  requirements  drawn 
from  the  broad  set  of  user  requirements  listed  above.  Additionally,  it 
should  be  noted  that  the  items  mentioned  here  are  discussed  in  a 


generic  wargaming  context  as  an  attempt  to  provide  a  general  feasibil¬ 
ity  framework  and  foundation  for  application- specific  issues. 

l.  T3ifi.PlftlQg-.Vnlt 

Within  the  dialog  unit,  one  must  assume  varying  degrees  of 
computer  literacy.  Use  of  a  wargaming  system  should  primarily  pro¬ 
vide  for  the  development  of  warfare  skills  as  opposed  to  computer 
skills.  This  implies  that  a  high  level  of  sophistication  must  exist  in  the 
user  interface  to  remove  the  user  from  the  problems  associated  with 
conventional  computer  interfaces.  As  recommended  by  the  survey 
participants,  a  highly  graphic -based  system  can  help  provide  the  level 
of  sophistication  desired. 

Objects  familiar  to  a  military  officer  may  be  graphically 
depicted  so  that  a  minimum  of  textual  information  must  be  read  and 
interpreted.  This  is  in  support  of  the  time  constraints  faced  during 
the  play  of  a  real-time  or  accelerated  wargame.  It  would  be  ideal  to 
provide  the  fastest  interface  possible.  High  resolution  in  the  graphics 
screen  allows  detailed  and  clear  representation  and  hence  interpreta¬ 
tion.  This  is  why  a  number  of  survey  participants  recommended  this 
option.  It  Is  not  only  desirable  but  rather  a  necessity  within  the  realm 
of  current  technology. 

To  effectively  use  this  graphic  technology,  the  user  input 
hardware  technology  should  be  at  least  as  sophisticated  as  the  output 
device  to  remove  the  user  from  interfacing  with  conventional 


input/output  devices  such  as  keyboards.  This  hardware  should  consist 
of  some  type  of  pointing/picking  device.  As  suggested  in  the  survey, 
user  familiarity  with  and  acceptance  of  the  mouse  is  fairly  broad  today. 
This  lends  the  mouse  a  bit  of  an  advantage,  although  other  technolo¬ 
gies  have  certain  merits. 

In  particular,  touchscreens  require  no  peripheral  device,  no 
tracking  area  on  the  desktop,  and  are  readily  available  to  the  player. 
In  the  same  context,  though,  touch  screens  and  other  devices  may 
pose  problems  of  their  own.  The  touchscreen  is  at  times  difficult  to 
implement  and  “fine  tune"  for  detailed  work  such  as  pixel  manipula¬ 
tion  because  of  finger  sizes  and  screen  divisions.  No  single  device  is 
perfect,  but  the  mouse  is  a  strong  candidate  if  it  can  be  effectively 
integrated  into  the  needs  of  the  specific  application. 

Thirty-eight  percent  of  the  participants  suggested  that  voice 
input/output  is  the  ideal  medium  for  use  in  wargaming.  This  may  be 
the  fastest  method  available  if  Implemented  under  “ideal"  circum¬ 
stances  of  very  high  levels  of  sophistication.  This  technology  is  still 
young  and  will  continue  developing  into  more  reliable  and  promising 
implementations.  Voice  technology  shows  much  promise  and  should 
be  considered  for  further  research  within  the  wargaming  application. 

With  the  recommendation  of  high-resolution  graphics  capa¬ 
bilities  and  improved  hardware,  software  implementations  should 
address  the  utilization  of  detailed  screen  graphic  manipulation.  The 


possibilities  include,  as  suggested  by  the  survey,  windows,  menus,  and 
icons  within  an  environment  of  graphic  manipulation  where  the  user 
can  perform  tasks  by  operations  on.  or  with,  the  graphic  objects. 

These  elements,  coupled  with  the  processing  capability  to 
provide  the  power  and  speed  demanded  by  such  graphic  manipulation, 
provide  a  foundation  environment  on  which  to  build  application  spe¬ 
cific  implementations  of  the  dialog  unit  within  a  wargaming  system. 

2.  The  Control  Unit 

Since  the  control  unit  must  provide  for  error-free  operation, 
the  hardware  and  software  must  be  proven  robust  enough  to  handle  all 
potential  error  situations  and  provide  on-line  help,  automatic  feed¬ 
back.  and  forgiving  continuation  of  the  wargame  process.  Extensive 
testing  and  evaluation  of  any  control  unit  is  a  necessity,  but  in  a 
wargaming  system,  with  numerous  data  elements  and  parameters 
which  need  to  be  verified  throughout  the  game,  a  dedicated  processor 
is  recommended  to  reduce  the  processing  burden  on  the  other  system 
components. 

Survey  participants  felt  that  the  on-line  help  facility  was  the 
most  important  part  of  the  control  unit.  While  it  is  terribly  important, 
at  least  as  much  effort  should  be  spent  in  making  the  control  unit 
informative  to  the  player  by  providing  unsolicited  guidance  during 
game  play.  All  players  make  mistakes,  even  the  experts.  It  is  usually 
the  novice  who  may  not  know  how  to  recover.  The  system  should 


allow  flexibility  here  to  give  the  expert  an  alert  of  a  problem  without 
the  drudgery  of  details,  but  also  give  the  novice  the  option  of  specific 
guidance  out  of  the  problem  area. 


3.  The  Inter-Module  Linkage  Unit 

Since  this  module  provides  the  interface  between  the  user’s 
input  from  the  dialog  unit  and  the  model  and  data  components,  it  is 
imperative  that  the  hardware  and  software  be  fast,  reliable,  and  easily 
maintained.  Thus  the  survey  participants  were  accurate  in  predicting 
the  need  for  modular  implementation  of  this  unit.  It  must  be  easily 
maintained  and  modified  as  data  elements  and  model  components 
change. 

The  link  performed  by  this  unit  is  very  time-critical  to  game 
play.  Player  requests  for  data  access  should  be  easily  and  rapidly 
served  by  this  unit.  This  can  be  enhanced  by  a  dedicated  processor 
capable  of  handling  the  interactive  model  as  well  as  data. 

Each  of  the  three  units  of  the  user  interface  framework  is 
critical  in  the  provision  of  a  complete  environment  which  wargaming 
systems  developers  must  address  individually.  The  components  work 
together  as  a  whole  to  establish  a  framework  for  wargame-specific 
decisions.  The  generic  framework  established  here  is  only  the 
foundation  of  that  task  on  which  much  elaboration  takes  place  in  actual 
development. 


V.  APPLICATION  OP  AVAILABLE  TECHNOLOGY 


The  concepts  discussed  to  this  point  have  indicated  several 
proven  effective,  available  modes  of  technology  which  the  author 
believes,  if  properly  applied,  may  bring  positive  results  to  the  military 
wargaming  arena. 

As  has  been  stated  a  number  of  times  in  this  thesis,  each  applica¬ 
tion  must  be  evaluated  independently  for  specific  implementations  of  a 
visual  or  other  effective  user  interface.  However,  guided  direction 
tempered  with  good  solid  research,  and  strong  prototyping  and  test¬ 
ing  will  undoubtedly  prove  effective  in  producing  improvements.  It  is 
therefore  highly  recommended  that  efforts  in  this  area  be  actively 
pursued  in  military  wargaming.  The  following  model  may  provide  a 
beginning  framework. 

A.  AN  INTEGRATED  FRAMEWORK 

Human  beings  gather  information  in  many  ways.  Since  human 
information  gathering  is  sensory  in  nature,  it  would  seem  logical  to 
support  the  sensory  system  as  fully  as  possible.  With  a  visual  interface 
alone,  even  though  highly  effective,  only  one  channel  is  open  for  com¬ 
munication.  With  the  integration  of  a  voice  input/output  system, 
another  channel  is  opened.  Together,  the  auditory  and  the  visual 
aspects  could  be  more  complete  and  meaningful. 

This  combination  also  supports  the  human  cognitive  processes 
through  integrated  visual  and  auditory  stimulation.  Long-term  memory 
requirements  are  minimized.  Visual  and  auditory  Information  can  be 
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processed  much  more  rapidly  than  textual  information  if  the  repre¬ 
sentations  are  meaningful.  Anxiety  levels  will  be  low  because  of  famil¬ 
iar  graphic  object  representations  and  the  intuitive  operations  to  be 
performed  on  those  objects.  Strong  feedback  and  ease  of  recovery 
from  errors  will  promote  user  acceptance.  Most  important,  the  user’s 
attention  is  now  directed  at  the  wargame  instead  of  trying  to  figure  out 
what  to  do  to  effect  commands  or  interpret  cryptic  output. 

Consider  a  wargaming  system  using  this  integrated  technology.  If 
a  player  were  to  approach  a  wargaming  system  which  is  implemented 
with  a  relevant,  well-developed  metaphor  for  wargaming,  recognition 
and  interest  would  immediately  develop.  If  operations  were  intuitive 
rather  than  obscure,  a  player  would  feel  more  comfortable  in  learning 
and  using  the  system.  The  concepts  would  allow  more  recognition 
than  memorization,  thus  lending  additional  simplicity  for  all 
concerned. 

The  visual  aspects  alone  in  an  application  such  as  wargaming  have 
tremendous  potential.  Military  maps  and  symbology  are  largely  stan¬ 
dardized  within  service  branches.  The  “grabbing"  and  “dragging"  of 
icons  and  symbols  in  the  Macintosh  system  are  certainly  useful  con¬ 
cepts  in  effecting  unit  movements  and  route  selection.  If  extended  to 
voice  input/output  operations  such  as  those  in  the  Dataland  system 
(Bolt.  1984),  a  player  could  simply  point  and  say  “move  that  there." 
There  is  no  need  for  fill-in  templates  or  complex  commands  contain¬ 
ing  long  sequences  of  numbers. 


A  workstation  with  enhanced  capabilities  and  high  performance  is 
necessary  for  fast,  high  quality  graphics  and  data  processing.  This  may 
be  accomplished  with  a  sophisticated  system  such  as  the  SUN  or  the 
APOLLO,  but  a  less  expensive  alternative  might  be  use  of  a  low-cost 
microcomputer  such  as  the  Macintosh. 

Regardless  of  the  system  chosen,  it  is  suggested  that,  rather  than 
support  numerous  screens  per  station,  use  one  high-capability 
screen/terminal.  With  windowing  and  complex  graphic  capabilities, 
one  screen  can  provide  one  central  information  control  unit. 
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Interface 

The  variations  of  visual  wargaming  interface  elements  have 
numerous  possibilities  within  the  contexts  of  actual  wargaming  sys¬ 
tems.  It  is  important  to  define  in  general  terms  how  the  visual  ele¬ 
ments  of  a  wargaming  interface  may  be  characterized.  It  is  also 
important  to  note  that  if  properly  developed,  these  elements  may  be 
further  developed  into  a  “standard"  group  of  wargame  interface  tools, 
such  as  the  elements  and  functions  of  the  Macintosh  Toolbox.  The 
fundamental  elements  to  be  addressed  here  are  icons,  windows,  dialog 
boxes,  alert  boxes  and  controls,  as  well  as  the  menu  bar  and  pull  down 
menus. 

a.  Icons 

Icons  are  graphic,  symbolic  representations  of  files, 
applications,  or  program  functions.  They  may  be  moved,  activated, 
deactivated,  or  otherwise  manipulated  in  standard  ways.  Icons  are 
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useful  because  they  contribute  greatly  to  the  clarity  and  attractiveness 
of  an  application. 

When  used  as  a  part  of  the  Apple  Desktop,  icons  gener¬ 
ally  have  associated  titles  listed  in  text  just  below  the  icon.  When  used 
in  an  application,  titles  may  or  may  not  be  used  depending  on  the  pur¬ 
pose  of  the  icon  and  the  intuitiveness  of  that  purpose. 

Each  icon  or  type  of  icon  has  a  distinctive  appearance  for 
rapid  recognition  by  the  user.  Apple  recommends  that,  wherever  an 
explanation  or  label  is  needed  in  an  application,  one  should  consider 
using  an  icon  (Apple  Computer,  1986,  p.  38). 

As  previously  stated,  icons  are  graphic  representations  of 
files,  applications,  or  program  functions.  Wargaming  is  an  ideal  area  in 
which  to  use  icons  because,  in  many  cases,  well-developed  military 
symbology  already  exists.  Although  not  usually  standardized  across 
military  branches,  the  accepted  and  understood  symbologies  are  read¬ 
ily  adaptable  to  the  visual  interface. 

The  JTLS  wargame  already  utilizes  standard  Army  ground 
combat  symbology  to  display  unit  position  on  the  geographic  display. 
BGTT  uses  the  Navy  standard  NTDS  symbology  for  the  same  purpose. 
This  is  an  obvious  use  of  the  available  symbology,  but  the  use  of  icons  in 
wargames  should  be  extended  far  beyond  this  traditional  method. 

The  potential  for  icon  utilization  begins  with  a  very  sim¬ 
ple  but  effective  foundation.  For  example,  in  JTLS,  the  player  of  the 
command  terminal  has  an  initial  choice  of  several  fundamental  types  of 
orders.  These  orders  are  categorized  into  operational  groups  of 
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ground  combat,  air  combat,  intelligence,  logistics,  and  so  on.  Rather 
than  issuing  a  complex  typed  command  stating  that  the  player  wants  a 
certain  amount  of  fuel  transported  to  a  certain  unit,  then  having  to  go 
through  sequential  menus  and  entry  of  parameters  in  the  necessary 
templates,  the  visual  solution  might  offer  a  far  superior  alternative. 

The  visual  implementation  should  allow  the  player  to 
“click"  the  logistics  symbol  (in  this  case,  maybe  a  transport  truck)  to 
designate  that  function.  That  function  should  respond  by  offering  the 
further  selections  of  fuel,  men,  food,  equipment,  or  ammunitions. 
These  items  also  lend  themselves  to  easily  recognizable  graphic 
representation  as  icons.  Also  note  though  that  each  icon  can  be 
labelled  if  so  desired  or  necessary.  This  provides  quick,  clear,  and 
precise  recognition  of  the  choices. 

If  the  player  were  to  follow  the  order  through  to  send 
fuel  to  a  unit,  he  would  select  the  fuel  icon,  at  which  time  a  dialog  box 
would  prompt  him  for  the  amount  of  fuel  and  the  desired  delivery 
time.  The  fuel  load  could  be  represented  on  a  bar  scale  with  a  sliding 
indicator  and  the  time  could  be  designated  with  a  clock  whose  hands 
could  also  be  moved  by  a  mouse  action.  After  the  selection,  the  player 
could  “drag"  the  fuel  load  icon  produced  by  his  actions  to  the  unit  or 
units  of  his  choice  on  the  geographic  display  in  a  nearby  window. 

The  possibilities  for  implementation  of  icons  in 
wargames  are  almost  endless.  But  more  importantly,  they  can  be 
implemented  very  effectively.  The  symbols  should  be  easily  recogniz¬ 
able  objects,  with  labels  if  desired  or  necessary.  They  should  be  items 
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which  are  common  and  clear  to  the  user  of  the  system.  The  user 
should  be  able  to  relate  to  the  meaning  and  intent  of  the  well  designed 
icon.  See  Figure  5. 

b.  Windows 

A  window  is  the  “frame”  through  which  a  user  views  and 
accesses  a  document.  Depending  on  the  type  and  size  of  a  document, 
all  or  part  of  it  may  be  viewed  in  the  window  at  any  given  time.  A 
number  of  windows  may  be  on  the  screen,  displaying  the  document  in 
use  as  well  as  other  open  documents  and  any  associated  information. 
Since  a  particular  window  represents  a  document,  it  is  recommended 
that  actual  document  contents  not  be  spread  to  multiple  windows.  To 
prevent  such  ambiguity,  split  or  partitioned  windows  are  used. 

The  standard  document  window  contains  certain  charac¬ 
teristics  used  for  conuJ  informational  purposes.  These  character¬ 
istics  include  a  close  box,  a  title  bar,  a  zoom  window  box,  and  a  scroll 
bar  which  includes  a  scroll  arrow  and  a  scroll  box. 

The  functions  of  these  items  are  fairly  intuitive  in  that  a 
zoom  box  allows  one  to  zoom  in  and  out  on  the  window  contents.  The 
close  box  allows  the  option  of  closing  a  document  by  clicking  the 
mouse  while  the  cursor  is  within  the  designated  area. 

The  scroll  box  allows  a  document  to  be  scanned  in  a  cho¬ 
sen  direction,  whether  it  be  vertical  or  horizontal.  The  scroll  box  acts 
much  like  an  elevator  in  a  shaft.  The  relative  position  of  the  box 
within  the  shaft  shows  the  user  his  relative  position  within  the 
document. 


Figure  5 

Icons 

Windows  may  exist  on  different  planes.  This  allows 
applications  to  have  more  than  one  window  open  at  once.  Windows 
may  overlap  each  other.  One  window  is  “active"  while  the  others 
remain  inactive.  The  “active"  window  refers  to  the  window  currently 
being  used.  To  bring  a  window  to  active  status  so  that  its  contents  may 
be  manipulated,  the  user  must  select  it  by  merely  clicking  anywhere 
within  the  window  itself.  This  brings  the  selected  window  to  the  front 
of  the  others  and  places  it  in  plain  view.  The  user  is  therefore  capable 
of  moving  around  between  windows  just  as  he  would  with  sheets  of 
paper. 

Windows  have  additional  versatility.  They  can  be  resized, 
and  moved  to  satisfy  the  user’s  changing  needs.  Windows  are  capable 
of  displaying  text,  graphics,  or  a  combination  of  the  two.  See  Figure  6. 

As  mentioned  above,  the  user  may  need  to  move  icons 
within  or  between  windows.  Windows  provide  the  user  with  relevant 
information  within  logical  “frames"  of  reference.  Windows  may  be 
effectively  utilized  in  a  wargame  environment  to  provide  the  player 
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Figure  6 

Wargame  Database  Window  With  Attributes 


with  the  necessary  Information  as  well  as  a  means  of  manipulation  of 
that  information. 

The  geographic  display,  which  is  of  primary  importance 
in  a  wargame  interface  of  any  type,  is  an  ideal  candidate  for  display  in  a 
window.  The  geographic  display  must  be  capable  of  displaying  con¬ 
cise,  current  information  about  unit  status,  action,  and  interaction. 

The  geographic  display  in  current  implementations  has  a 
tendency  to  become  cluttered  and  difficult  to  interpret  because  of  the 
requirement  for  a  high  level  of  detail.  For  that  reason,  wargames  such 
as  JTLS  and  BGTT  are  capable  of  decluttering  the  separate  graphics 


screen  by  selection  of  specific  items  to  be  displayed  and  by  changing 
the  scale  of  the  display. 

The  geographic  display  should  occupy  a  window  on  the 
user’s  primary  screen.  The  window  should  be  capable  of  movement, 
opening  and  closing,  resizing,  and  handling  different  levels  of  planes, 
just  as  in  any  good  window  implementation.  The  distinction  between 
the  traditional  implementation  and  the  visual  implementation  though 
should  lie  in  the  degree  of  user  control  over  the  window.  See  Figure  7. 

The  geographic  window  should  be  available  to  the  user  at 
the  “click”  of  a  mouse  or  any  other  similarly  quick  device.  The  user 
should  not  only  be  able  to  observe  the  results  of  his  typed  commands 
as  in  other  systems,  but  rather  the  user  should  be  able  to  directly 
manipulate  objects  on  the  display.  Design  should  allow  effective 
movement  of  objects  within  and  in  between  windows  providing  the 
user  with  more  intuitive  tools.  This  is  a  means  to  increased  speed  and 
understanding  for  the  user.  For  instance,  to  call  a  unit  in  to  the  arena, 
just  “drag"  the  appropriate  symbol  from  one  window  to  the  active 
geographic  display. 

With  a  drop-down  menu  bar  selection,  any  requested 
status  information,  database  query,  or  geographical  display  can  be 
immediately  available.  See  Figure  8.  Windowing  will  allow  simultane¬ 
ous  viewing  and  manipulation  of  several  vital  screens.  The  geographic 
display  window  should  allow  immediate  unit  information  retrieval  for 
items  such  as  current  activity,  pending  orders,  strength,  losses,  com¬ 
munication  paths,  resources  available,  and  so  on. 


Figure  8 

Typical  Pull-Down  Menu 
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Windows  in  a  wargame  should  be  flexible  but  with  enough 
structure  to  avoid  ambiguity.  The  user  should  be  able  to  call  upon  and 
graphically  manipulate  as  much  information  as  possible  without  fre¬ 
quent  switches  between  the  keyboard  and  the  graphics  input  device. 
This  is  not  entirely  avoidable,  but  in  other  systems  it  is  not  uncommon 
to  control  the  graphic  display  with  cumbersome  typing  of  commands. 
In  the  visual  interface,  for  instance,  to  zoom  in  or  out  of  the  geo¬ 
graphic  window,  a  click  in  the  appropriate  “zoom  box"  will  effortlessly 
step  the  user  to  the  next  level  of  detail. 

Another  possible  use  of  windows  in  the  wargame  is  to 
provide  “information  planes"  whereby  the  user  may  select  different 
levels  of  windows  through  icons,  or  whatever  means,  to  provide  dif¬ 
fering  resolutions  of  information  for  the  player.  For  instance,  if  the 
player  is  accessing  the  game  data  or  a  player  report,  a  “double  click" 
on  the  window  should  provide  the  information  in  greater  detail.  A 
“single  click"  on  the  window  should  provide  an  abbreviated,  more 
general  view  of  the  information. 

c.  Dialog  Boxes,  Alert  Boxes,  and  Controls 

In  addition  to  standard  windows,  there  are  other  kinds  of 
windows.  These  are  dialog  boxes,  alert  boxes,  and  controls.  These  are 
not  windows  in  the  strict  sense  but  rather  auxiliary  types  of  windows 
which  provide  specific  functions. 

Dialogs  allow  the  system  to  prompt  the  user  for  addi¬ 
tional  information  before  a  command  is  executed.  Dialog  boxes  are 
either  modal  or  modeless.  A  modal  dialog  box  requires  that  the  user 


dismiss  the  box  by  performing  a  specific  action  or  acknowledgement 
before  doing  anything  else.  A  modeless  dialog  box  allows  the  user  to 
perform  other  operations  without  dismissing  the  box. 

Dialog  boxes  in  the  wargame  interface  will  provide  a  clear 
method  of  communication  with  the  user.  For  instance,  if  the  system  is 
in  need  of  parameters  or  information  which  the  user  for  some  reason 
has  not  specified,  the  dialog  box  will  appear  to  inform  and  prompt  the 
user  for  the  appropriate  items.  An  example  of  this  may  be  in  the 
logistics  example  used  previously.  The  user  indicated  that  fuel  was 
required,  but  the  wargame  needs  to  know  the  quantity  and  delivery 
time.  A  dialog  box  could  tell  the  user  that  the  information  is  needed, 
specify  the  parameter  range,  and  wait  for  the  response. 

It  is  important  in  dialog  boxes  that  the  user  maintain 
control  of  the  system  such  that  the  user  is  not  forced  to  input  the 
parameters.  The  dialog  box  usually  will  allow  a  "cancel"  function  along 
with  appropriate  warnings  and  statements  of  consequence  to  allow  the 
user  some  degree  of  flexibility. 

Alerts  notify  the  user  in  the  event  of  an  unusual  situation, 
such  as  an  error  condition.  Since  users  are  error  prone,  alert  boxes 
allow  the  system  to  Inform  them  that  a  mistake  has  occurred.  The 
significance  of  the  mistake  and  guidance  for  recovery  are  usually 
included  in  the  text.  See  Figure  9. 

Alerts  in  a  wargame  can  be  used  to  warn  the  players  of 
threats  within  the  game  Itself  as  well  as  to  warn  the  players  of  unusual 
situations  and  system  error  conditions.  Guidance  should  be  provided 
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Figure  9 

Typical  Alert  Box 

to  inform  the  user  of  appropriate  actions  and/or  recovery  procedures 
so  that  wargame  play  can  be  continued  with  as  little  difficulty  as 
possible. 

Controls  are  graphic  objects  which  can  be  manipulated 
with  the  mouse  to  perform  instant  actions,  either  visually  or  audibly. 
Controls  can  have  four  basic  varieties:  buttons,  check  boxes,  radio 
buttons,  and  dials. 

Buttons  are  small  objects,  found  usually  within  a  window, 
labeled  with  text  or  an  icon.  A  button  performs  an  instantaneous  or 
continuous  action  described  by  associated  text.  Check  boxes  act  like 
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toggle  switches  to  turn  functions  on  or  off.  Radio  buttons  occur  In 
groups  in  which  only  one  radio  button  can  be  active  at  the  time.  Dials 
display  a  value  or  magnitude  which  is  alterable  by  the  user  (Apple 
Computer.  1983,  pp.  32-  33). 

Controls  are  graphic  objects  which  can  be  used  to 
increase  and  enhance  the  manipulation  characteristics  of  the 
wargame.  Familiar  objects  may  be  graphically  depicted  to  guide  the 
user  to  the  choices  available.  For  instance,  to  turn  on  radar,  a  player 
may  “click"  on  a  graphically  depicted  toggle  switch  or  button,  or  to 
increase  the  sensitivity  of  some  equipment  the  player  may  turn  a  dial. 
There  are  numerous  possibilities  for  implementation  of  control  ele¬ 
ments  in  wargame  systems.  See  Figure  10. 

d.  Menu  Bar  and  Pull-Down  Menus 

The  menu  bar  is  displayed  at  the  top  of  the  screen.  It 
contains  logically  grouped  titles  of  the  pull-down  menus  which  are 
available  to  the  user  for  expressing  commands.  Pull-down  menus  may 
consist  of  text  or  graphic  entries.  Each  application  usually  has  its  own 
menu  bar  to  make  program-specific  selections  available.  These  selec¬ 
tions  remain  constant  throughout  the  application,  though  all  com¬ 
mands  r.iay  not  be  available  or  operative  at  all  times.  Users  are  always 
able  to  peruse  the  available  commands  while  maintaining  the  informa¬ 
tion  being  worked  on  in  the  current  document  on  the  screen. 

The  menu  bar  and  pull-down  menus  are  ideal  for  imple¬ 
mentation  in  wargaming  systems.  The  menu  bar  provides  for  cate¬ 
gories  of  commands  to  be  actively  displayed  for  selection  during  game 
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play.  The  pull-down  menus  allow  the  user  to  select  specific  com¬ 
mands  from  those  categories.  The  benefits  in  a  wargaming  system  are 
that  the  user  has  only  to  recognize  a  command  to  use  it.  Cryptic 
command  structures  do  not  have  to  be  memorized  or  frequently  refer¬ 
enced.  See  Figure  11. 

The  menu  bar  should  contain  standard  commands  and 
functions  for  all  players,  but  depending  on  the  command  needs  of  the 
player  station,  the  menus  and  menu  bars  will  vary  accordingly.  A  point 
of  caution  should  be  noted  here.  With  the  large  number  of  commands 
usually  necessary  in  wargaming  systems,  care  should  be  taken  to  avoid 
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Figure  11 

Menu  Bar  With  a  Pull-Down  Menu 

confusing  and  numerous  menus.  Careful  design  and  integration  will 
avoid  associated  problems. 

B.  HARDWARE/SOFTWARE  REQUIREMENTS 

The  hardware  is  composed  of  a  number  of  high-speed  worksta¬ 
tions,  each  consisting  of  a  large-surface,  high-quality,  high-resolution 
graphics  monitor  and  a  pointing  device  or  touch  screen  with  a  key¬ 
board  for  manual  input.  The  workstation  ideally  has  extensive  local 
graphic  processing  and  database  storage  capabilities. 

Hardware  and  software  requirements  will  vary  widely  depending 
on  the  extent  and  method  of  implementation.  Workstations  are 
becoming  more  and  more  popular  due  to  their  strength  and  flexibility. 
They  are  also  providing  more  value  per  dollar  as  hardware  prices 
decline.  As  mentioned  above,  the  SUN  and  APOLLO  are  examples  of 
such  systems,  but  advanced  microcomputers  such  as  the  Macintosh 
might  easily  serve  as  low-cost  alternatives,  especially  in  the  develop¬ 
ment  stages. 
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C.  IMPLEMENTATION:  A  SESSION  IN  JTLS 

This  portion  of  the  thesis  will  address  two  scenarios:  1)  a  JTLS 
wargamer  stepping  through  a  task  in  the  current  interface,  and  2)  a 
JTLS  player  stepping  through  the  same  task  in  a  hypothetical  visual 
interface.  Figure  12  illustrates  a  comparison  of  the  man-machine 
interactions  for  the  two  scenarios. 
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The  current  JTLS  interface,  as  described  previously,  is  menu- 
based.  A  player  involved  in  a  JTLS  wargame  is  faced  with  sending 
numerous  commands  under  tight  time  constraints.  The  scenario  to  be 
addressed  here  is  for  the  ground  terminal  player  to  create  an  attack 
mission.  This  involves  a  common  operation  for  the  ground  player  and 
resembles  tasks  which  other  players  must  perform  on  a  regular  basis. 

At  this  point  in  the  game,  the  player  has  already  been  playing 
actively,  building  and  sending  directives  to  perform  various  actions.  It 
is  common  in  the  current  version  of  JTLS  for  the  player  to  reuse 
directives  created  previously  by  modifying  them  to  reflect  newly 
desired  parameters  as  the  game  progresses.  This  is  done  because 
modification  of  previously  built  orders,  while  still  tedious,  takes  con¬ 
siderably  less  time  than  developing  new  ones.  However,  in  this  case, 
the  player  is  creating  a  new  attack  directive. 

Assuming  that  this  player  is  new  to  JTLS,  he  will  first  attempt 
to  refresh  his  memory  with  a  menu  option  which  might  allow  him  to 
inform  himself  how  to  perform  this  task.  His  first  action  will  be  to 
type  "?"  in  an  attempt  to  display  the  top-level  directives  (assuming  he 
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Figure  12 

Comparison  of  typical  Man-Machine  Interactions 
For  the  Two  JTLS  Scenarios 


is  currently  at  the  top  level  of  the  menu  structure).  If  the  player  is  at 
the  top  level,  he  will  see  a  screen  display  of  menu  options,  three  of 
which  will  allow  the  player  to  move  into  a  manipulation  level.  He  finds 
the  command  desired  at  this  time,  the  “Create"  directive. 

Again,  as  a  novice,  the  player  may  have  forgotten  the  next 
syntactical  element  to  be  entered,  therefore,  he  will  type  "CR  ?"  to 
display  his  options  at  the  manipulation  level.  “Attack"  appears  in  the 
list  as  option  number  three  out  of  seventeen  available  choices  now  on 


the  screen.  The  player  then  recognizes  the  command  and  enters  “CR 
AT."  which  is  the  abbreviated  form  of  “CREATE  ATTACK." 


After  this  entry,  a  template  for  the  attack  directive  appears 
on  the  screen.  This  particular  template  has  nine  parameters  which 
must  be  completed.  In  addition,  the  completion  of  another  entirely 
different  directive  sequence  and  template  is  necessary  to  provide  the 
ground  route  for  the  attacking  forces,  the  name  of  which  is  provided 
as  the  ninth  parameter  of  this  first  template. 

During  template  completion,  feedback  is  minimal.  The  first 
parameter  in  the  attack  template  is  called  “REFERENCE."  This  is 
actually  a  name  by  which  the  player  may  reference  this  particular 
directive  after  completion,  e.g.,  for  the  directive  to  be  sent  to  the 
game  for  execution.  The  player  may  insert  any  name  which  he 
considers  appropriate  here,  but  when  the  player  attempts  to  enter  the 
parameter  for  item  number  three,  “UNIT,"  the  player  must  be  able  to 
specify  an  accurate  unit  name  which  is  active  in  the  current  game 
database.  Otherwise,  the  game  will  respond  with  “There  are  no 
GROUND  units  whose  name  begins  with  82A."  Unfortunately,  the 
player  at  this  point  must  escape  his  current  activity  and  review  the 
database  for  an  accurate  name.  This  is  time  consuming  and  trouble¬ 
some,  especially  for  the  novice,  but  it  happens  to  all  types  of  players  at 
one  time  or  another. 

After  the  player  finds  an  appropriate  entry  for  the  name 
parameter,  he  must  reenter  the  template  (if  he  knows  how)  arid  con¬ 
tinue  along  the  same  path  until  the  directive  and  the  ground  route  are 


complete.  The  player  then  must  return  to  the  top  level  and.  when 
ready,  recall  the  directive  for  the  “SEND"  operation  to  actually  enter 
this  directive  into  game  play. 

This  is  an  abbreviated  hypothetical  case  used  as  an  example 
only.  A  number  of  sample  command  sequences  may  be  followed  in  the 
JTLS  Player  Guide  (CPS.  1984) 

2.  A  Visual  JTLS  Interface  Scenario 

In  this  scenario,  the  JTLS  player  sees  a  much  different  por¬ 
trayal  of  the  system.  The  player  screen  consists  of  a  menu  bar  across 
the  top  of  the  screen.  The  menu  bar  always  contains  a  pull-down 
menu  for  the  currently  available  wargame  “DIRECTIVES"  as  well  as  a 
“HELP"  pull-down  menu,  a  “GENERAL  PURPOSE"  or  “UTILITY"  pull¬ 
down  menu,  and  a  “WINDOWS"  pull-down  menu.  The  menu  bar  may 
vary  in  content  or  accessibility  with  the  current  game  modes  or  player 
choices. 

The  “GENERAL  PURPOSE"  or  “UTILITY"  menu  provides 
functions  which  are  useful  during  any  part  of  game  play,  such  as 
“CANCEL"  to  quickly  escape  the  current  series  of  player  actions. 
Upon  selection,  the  cancel  option  presents  a  dialog  box  asking.  “Will 
you  resume  this  operation  later?  If  so,  it  will  be  saved,  if  not  it  will  be 
destroyed."  At  this  point,  the  player  may  point  and  click  to  either  the 
“SAVE"  or  “CANCEL"  options  according  to  his  situation. 

The  “WINDOWS"  pull-down  menu  allows  the  user  access  to 
various  informational  displays,  such  as  the  geographic  display  or  the 


database  query  window,  which  is  capable  of  displaying  textual  and 
graphic  database  information. 

Additional  items  appearing  on  the  screen  may  be  a  palette  of 
icons  used  for  common  operations  which  are  modal  in  nature,  such  as 
the  designation  of  ground  units,  or  weapon  load  creation,  or  message 
sending.  For  instance,  a  telephone  icon  is  resident  in  the  palette  at  all 
times,  just  as  a  communications  device  would  be  at  the  commander’s 
disposal.  The  player  uses  his  mouse  to  click  on  the  telephone  icon  to 
activate  communication.  Immediately,  a  dialog  box  appears  requesting 
the  sendee's  name  or  identification.  The  available  choices  within  the 
current  game  appear  in  a  scroll  region  to  be  readily  accessible  to  the 
caller.  The  caller  may  scroll  until  he  finds  the  correct  entry,  at  which 
time  he  may  double  click  to  select  that  party,  or  if  multiple  parties  are 
desired,  he  may  press  the  shift  key  on  the  keyboard  and  click  any 
number  of  parties,  each  of  which  is  highlighted  as  he  clicks  on  the 
entry.  When  finished  he  clicks  on  the  text  input  region  and  types  the 
message.  He  may  at  any  time  click  either  a  “SEND"  box  or  a 
“CANCEL"  box  as  appropriate. 

To  accomplish  game  directives  as  in  the  current  JTLS  inter¬ 
face  example  above,  the  player  initiates  action  by  placing  the  cursor  on 
the  menu  bar  above  the  “DIRECTIVES"  category.  As  the  player 
presses  the  button  on  the  mouse,  a  pull-down  menu  containing  the 
currently  available  game  directives  is  displayed.  The  player  moves  the 
cursor  over  the  “CREATE"  directive  and  releases  the  mouse  button. 
Immediately  the  menu  bar  reflects  a  change  by  displaying  a  new  menu 


bar  selection,  “ACTIONS."  This  indicates  to  the  player  that  he  now 
has  the  option  of  continuing  his  directive  by  accessing  this  pull-down 
menu  as  well. 

Notice  one  thing.  The  user  still  may  change  his  mind.  If  he 
returns  to  the  “DIRECTIVE"  pull-down  menu,  he  may  cancel  the  pre¬ 
vious  selection  by  making  another  selection.  This  interface  is  event- 
driven,  not  hierarchical  as  in  the  other  JTLS  interface.  The  user  now 
decides  where  he  wants  to  be.  If  he  chooses  not  to  cancel,  and  con¬ 
tinues  in  his  original  path,  he  may  select  “ATTACK"  from  the 
“ACTIONS"  pull-down  menu. 

A  dialog  box  appears  immediately.  This  dialog  box  provides  a 
unique  reference  name  which  may  be  changed  if  desired.  A  scroll  box 
containing  candidate  unit  names  appears  to  provide  data  for  item 
number  three.  The  user  scrolls  to  the  appropriate  unit,  then  clicks  on 
it.  A  digital  clock  icon  appears  to  provide  for  the  execution  time  in¬ 
put.  The  user  clicks  on  up  and  down  arrows  to  indicate  the  appropri¬ 
ate  time,  then  clicks  outside  the  clock  icon  to  indicate  approval. 
Scroll  boxes  are  available  for  the  “ATTACK  WITH,"  “PROTECT  WITH," 
and  "SCREEN  WITH"  parameters.  These  may  be  ignored  if  no  entry  is 
desired. 

The  final  parameter  to  be  entered  is  the  “ROUTE"  which 
provides  a  path  for  the  unit  to  take  to  a  destination.  The  user  clicks 
on  “ROUTE"  to  indicate  that  he  is  ready  to  fill  this  parameter.  The 
geotactical  display  window  appears  with  the  specified  unit(s)  appear¬ 
ing  in  their  current  positions  on  the  map.  The  user  then  points  to  the 


unit(s),  presses  the  mouse  button,  and  moves  the  cursor  along  the 
desired  route  to  the  destination.  Notice  no  coordinates  were  looked 
up,  written  down,  or  repeated  by  another  person  as  usually  happens  in 
the  game. 

The  user  then  selects  “SAVE,"  “SEND,"  or  “CANCEL"  and 
the  directive  is  accomplished  with  a  minimum  of  effort.  The  support 
required  for  the  player  is  self  contained  in  one  workstation.  Several 
other  people  are  not  now  needed  to  chart  routes,  research  unit  or  tar¬ 
get  names,  or  provide  game  instructions. 

This  interface  provides  a  continuously  available  help  facility, 
and.  at  practically  any  point,  will  allow  the  user  flexibility  in  the  way  he 
wants  to  enter  commands  and  access  data  or  reports.  When  con¬ 
trasted  to  the  current  JTLS  interface.  It  seems  that  much  time  and 
effort  could  be  saved  in  this  type  of  implementation.  The  most  impor¬ 
tant  aspect,  though,  is  the  usability  of  such  an  interface.  The  user  will 
feel  much  more  comfortable  pointing  to  familiar  objects  than  typing 
complex  syntax.  The  user  will  be  more  comfortable  with  a  system 
which  he  feels  he  controls  and  which  is  most  forgiving  of  his  mistakes. 


In  a  foreword  to  Richard  Bolt’s  book,  Nicholas  Negroponte  of  MIT 
(1984)  makes  a  very  strong  case  for  Improvement  of  the  human  inter¬ 
face.  This  excerpt  is  included  here  because  it  strongly  reiterates  the 
ideals  of  this  thesis.  “The  human  interface  with  computers  is  the 
physical,  sensory,  and  intellectual  space  that  lies  between  computers 
and  ourselves.  Like  any  place  this  space  can  be  unfamiliar,  cold,  and 
unwelcoming.  But  it  can  also  be  like  some  other  places,  those  we 
know  and  love,  those  that  are  familiar,  comfortable,  warm,  and,  most 
importantly,  personal."  (Bolt,  1984.  foreword) 

User  benefits  have  been  emphasized  throughout  this  thesis.  It 
serves  no  practical  purpose  to  list  them  all  again,  but  it  does  serve  a 
practical  purpose  to  recognize  the  fact  that  the  benefits  from  such 
modification  of  user  interface  software  will  be  significant  for  all  users. 
The  novice  and  the  expert  will  both  experience  large  gains  in 
productivity.  The  long-term  development  of  the  visual  interface  into 
an  even  stronger  tool  holds  virtually  unlimited  potential.  It  is  limited 
only  by  the  imagination  because  eventually  the  technology  will  be  there 
to  support  it. 

The  Department  of  Defense  supports  vast  research  and  develop¬ 
ment  in  many  important  fields.  The  area  of  the  user-computer  inter¬ 
face  affects  all  of  us.  The  potential  benefits  of  friendly,  easily  under¬ 
stood  interfaces  are  innumerable. 


Only  through  dedication  to  the  ideal  of  making  computers  work 
for  us  will  we  ever  have  full  command  over  the  available  resources.  To 
ignore  readily  implementable  systems  which  will  establish  a  milestone 
foundation  for  the  advancement  of  the  military  and  society  in  general 
seems  wasteful  and  unproductive.  Implementation  of  such  interfaces 
will  open  new  avenues  of  communication  and  creativity  which  can  lead 
to  strong  positive  strategic  growth  potential. 

The  technology  discussed  in  this  thesis  is  readily  available  for 
application  to  the  wargaming  environment.  Implementation  costs  may 
be  high  for  full-scale  implementation,  but  long-term  benefits  should  be 
immense  to  the  Department  of  Defense.  If  managed  properly,  with 
small-scale  development  and  prototyping  followed  by  thorough  test¬ 
ing,  costs  can  be  cut  drastically.  It  is  very  inexpensive  and  simple  to 
develop  a  prototype  on  a  Macintosh  system  which  will  simulate  the 
workings  of  a  full-scale  implementation. 

It  is  expected  that  certain  elements  of  the  visual  interface  will 
productively  lend  themselves  to  the  improvement  of  the  visual 
wargame  interface.  These  elements  include: 

1 )  Extensive  use  of  metaphors,  icons,  and  familiar  graphic  symbol¬ 
ogy  to  promote  rapid  learning  and  transfer  of  knowledge  and 
understanding. 

2)  Use  of  windowing  for  centralized  attention  to  a  single  screen  for 
the  direct  manipulation  and  control  of  the  interface  by  the  user. 

3 )  Use  of  dialog  and  alert  boxes,  and  controls  for  ease  and  clarity  of 
communication  between  the  user  and  the  computer. 

4 )  Command  entry  by  menu  bar  and  pull-down  menus  for  availabil¬ 
ity  and  recognition  versus  memorization  of  commands. 


Further  research  in  the  area  of  specific  application  is  necessary. 
While  the  JTLS  and  BGTT  system  interfaces  are  good  candidates  for 
visual  interface  implementation,  it  will  be  necessary  in  follow-on  work 
to  develop  prototypes  which  will  effectively  implement  visual  princi¬ 
ples  as  well  as  model  the  wargame  systems  and  users.  Specific  rec¬ 
ommendations  for  the  development  and  implementation  of  advanced 
interfaces  include: 

1)  Thorough  requirements  analysis  of  the  wargame  user  interface 
from  a  user’s  perspective. 

2)  Research  of  graphic  workstation  technology  for  capacity,  capa¬ 
bility,  and  interface  evaluation. 

3)  Further  research  of  available  visual  interface  principles,  includ¬ 
ing  a  development  plan  for  application  specific  transfer  of 
principles. 

4)  Design  and  prototyping  of  interfaces  based  on  conclusions  of 
research. 

5)  Testing  and  evaluation  of  prototypes,  coupled  with  further 
refinement  based  on  results. 

6)  Evaluation  of  results  to  determine  common  elements  which  may 
be  applicable  to  the  development  of  a  “Toolbox”  type  of  interface 
tool  for  use  with  different  wargame  systems. 

It  would  be  most  interesting  and  productive  to  compare  the 
results  of  such  research  for  common  factors.  If  commonality  is  found, 
further  research  may  prove  useful  in  the  development  of  a  generic 
toolbox  system  for  implementation  of  these  and  other  wargame  sys¬ 
tems.  If  this  were  possible,  the  costs  could  be  spread  across  many 
applications,  while  benefits  of  standardization  of  a  very  good  interface 
could  multiply  with  use. 


Wargaming  is  becoming  an  invaluable  tool  in  strategic  force  plan¬ 
ning  and  analysis.  It  only  seems  prudent  to  bring  such  a  valuable  tool 
to  the  user  in  a  highly  refined  state.  Based  on  the  information  avail¬ 
able,  the  visual  interface—  and  in  the  near  future,  voice  technology— 
appear  to  be  a  most  practical  direction  for  substantial  improvement  in 


wargaming  systems. 
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